This makes it easier to work with multiple remotes at once while
tracking the default branch of the remote used to create the local
repository:
```shell
$ jj git clone --remote upstream https://github.com/upstream-org/repo
$ cd repo
$ jj git remote add origin git@github.com:your-org/repo
$ jj config set --repo git.fetch upstream
```
In the example above, `upstream` is the repository containing the
reference source code that you might want to patch, while `origin` is
your fork where pull-request will be pushed. The branch `main@upstream`
will be tracked.
Jujutsu's branches do not behave like Git branches, which is a major
hurdle for people adopting it from Git. They rather behave like
Mercurial's (hg) bookmarks.
We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord,
where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were
reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name
the current mechanism. This may be hard break for current `jj branch` users, but it will immensly
help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]`
config option is currently left alone, to force not another large config update for
users, since the last time this happened was when `jj log -T show` was removed, which immediately
resulted in breaking users and introduced soft deprecations.
This name change will also make it easier to introduce Topics (#3402) as _topological branches_
with a easier model.
This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from
me being lazy or thankfully pointed out by reviewers.
`jj rebase -r C -d A; rebase -s B -d C` is missing the second jj.
Although it would be cool if jj had syntax to chain commands like this, so I could write a "swap" alias.
i did the following things:
1. make some changes to the working copy
2. run `jj commit`
3. before i added a description, i decided i didn't want to commit yet. in git, the way to do this is to delete the contents of the editor; git sees that it is blank and aborts the commit. in jj, this doesn't work, because descriptions are allowed to be empty.
now i have the following jj state:
```
; jj log --stat
@ pokrsyvs github@jyn.dev 2024-02-06 21:48:17.000 -05:00 ddd6217f
│ (empty) (no description set)
│ 0 files changed, 0 insertions(+), 0 deletions(-)
◉ lqqmzmku github@jyn.dev 2024-02-06 21:48:02.000 -05:00 HEAD@git b03bf3de
│ (no description set)
│ config/jj.toml | 2 +-
│ 1 file changed, 1 insertion(+), 1 deletion(-)
◉ xqkmwvwp github@jyn.dev 2024-02-06 21:47:08.000 -05:00 master b673f97b
```
i want to undo the most recent commit, `lqqmzmku`. i'm used to doing this with `git reset --soft HEAD~`, which makes the parent `xqkmwvwp` and leaves the change to `config/jj.toml` on disk while removing it from the git history; basically `lqqmzmku` would go back to being the working copy.
i found that `jj move` does what i want, but it took a lot of trawling the options, it wasn't obvious, and i couldn't find `git reset` mentioned in the docs.
Summary: As discussed in Discord, on GitHub, and elsewhere, this change
deprecates the use of `jj checkout` and suggests users use `jj new` exclusively
instead. The verb `checkout` is a relic of a bygone era the — days of RCS
file locking, before 3-way merge — and is not a good, fitting name for the
functionality it provides.
To further drive the bit home, by default, `jj checkout` (and `jj co`) is now
hidden. This will hopefully stop new users from running into it.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Change-Id: I7a1adfc9168fce1f25cf5d4c4c313304769e41a1
I couldn't come up with a Git analogue of `jj log`, but I think it's OK
leaving it as a TODO makes the point. Perhaps somebody can figure it
out.
Also, all the correspondences are not completely precise, so I didn't
emphasize it every single time.
Wol on lwn.net pointed out that our current description in the Git
Comparison doc for why there is no staging area can be interpreted as
saying that it's because it simplifies the CLI. It took me a while to
see that interpretation, but it makes sense to me now. This patch
tries to clarify that we have better tools than the staging area for
manipulating commits.
Sadly, ripgrep won't honor the .gitignore files in the absence of a
.git directory, so we need to pass an annoying flag (for non-colocated
repos).
That seems worth adding despite the existing suggestion, because rg is
faster, and for existing users for rg, it would teach them how to make
rg work as expected.
IIUC, the consensus in the Git project is that the overloaded nature
of `git checkout` for many use cases was a mistake, and `git
switch/restore` are meant to replace it.
Since we now allow pushing open commits, we can implement support for
pushing the "current" branch by defining a "current" branch as any
branch pointing to `@`. That definition of a current/active seems to
have been the consensus in discussion #411.
Closes#246.
The command's help text says "Abandon a revision", which I think is a
good indication that the command's name should be `abandon`. This
patch renames the command and other user-facing occurrences of the
word. The remaining occurrences should be removed when I remove
support for evolution.
The table describes the simplified Git workflow of always using `git
commit -a`. With that workflow, you don't need to `git add` or `git
rm` to stage changes.
