Fetching changes while on a branch

[BatmanAoD]

jj git fetch has some behavior that surprised me at first, but makes sense because jj doesn't have tracking branches. After the following sequence of operations, the working copy does not have any new changes from the remote, and any new commits will create a fork in history:

jj checkout foo
jj git fetch

To avoid this, foo must be checked out again.

This doesn't matter if the local workspace is the only place where changes are being introduced along this branch, but even when branches aren't shared between developers, sometimes it's useful for CI to automatically create commits on a branch (e.g. if the CI process includes some kind of code-gen and the generated code is committed to the repository, as is I believe is typical with protoc and go gen). So here's the more awkward version of the above:

jj checkout foo
<do some work>
jj commit ...  [or squash and skip the `branch set`]
jj branch set foo -r @-
jj git push
<later, with no further local changes>
jj git fetch
jj checkout foo

Here, @ is empty when performing git operations, so there's no reason for a fork in history; and at no point did the user decide to work on a different branch or conceptual line of work. So the jj checkout foo at the end feels quite redundant.

This is pretty similar to previous discussions about auto-updating branch heads, but I don't think it's been explicitly called out before.

[martinvonz]

jj checkout foo
<do some work>
jj commit ...  [or squash and skip the `branch set`]
jj branch set foo -r @-
jj git push
<later, with no further local changes>
jj git fetch
jj checkout foo

Here, @ is empty when performing git operations, so there's no reason for a fork in history; and at no point did the user decide to work on a different branch or conceptual line of work. So the jj checkout foo at the end feels quite redundant.

Were there any changes made on the remote in this scenario? If not, the jj checkout foo is actually redundant, unless I'm missing something. Let's draw the graph at various points in time to clarify:

$ jj checkout foo
# @ y (empty) (no description set)
# |
# o x foo
$ jj commit -m blah
$ jj branch set foo -r @-
# @ z (empty) (no description set)
# |
# o y foo blah
# |
# o x foo@origin
$ jj git push
# @ z (empty) (no description set)
# |
# o y foo blah
$ jj git fetch
# @ z (empty) (no description set)
# |
# o y foo blah
$ jj checkout foo
# @ w (empty) (no description set)
# |
# o y foo blah

The only thing that happened in the last jj checkout foo command is that we got a new empty commit (change id w instead of z). If the foo branch had instead moved forward on the remote, the last two commands would look like this:

$ jj git fetch
# o w foo
# |
# | @ z (empty) (no description set)
# |/
# o y blah
$ jj checkout foo
# @ v (empty) (no description set)
# |
# o w foo

Does that clarify? I think our planned jj git sync will help in this case by rebasing the working copy onto the new foo target, making the jj checkout unnecessary.

[BatmanAoD]

Were there any changes made on the remote in this scenario?

Yes, that's what I was trying to explain here:

This doesn't matter if the local workspace is the only place where changes are being introduced along this branch, but even when branches aren't shared between developers, sometimes it's useful for CI to automatically create commits on a branch.

If there are no changes on the remote, the jj git fetch would be redundant, too. (Of course it will pick up changes to other branches, but I generally don't care too much about that if I'm not planning to check out a different branch any time soon.)

Automatic rebasing would indeed have the correct behavior, though technically no commits should be rewritten as long as the working state is clean; it should be a purely "fast-forward" merge, to use the git term.