[Question] Surprising history rewrite with jj git push --bookmark

[rami3l]

Summary

Hello there! I'm maintaining rustup and I'm learning to use jj for it, so please correct me if I have got anything wrong or have missed some configuration points 🙏

In rust-lang/rustup#4927 I'm trying to maintain a cross-fork backporting PR from origin:backport/202606 to upstream:release/1.29.

However, to my surprise, jj git push --bookmark backport/202606 --remote origin has also rewritten release/1.29 locally, causing unnecessary conflicts.

What could be going wrong? Is this a bug or my misunderstanding of how jj is supposed to be used? Many thanks in advance 🙏

PS: It should be noted that git push --force origin HEAD:backport/202606 does not trigger this behavior and works as expected; also I fetched beforehand, so this does not seem to be stale remote state.

Setup

• upstream = canonical repo
• origin = my fork
• local release/1.29 tracks release/1.29@upstream
• I create a local backport bookmark from release/1.29
• I cherry-pick commits onto that backport bookmark with rebasing
• I push only the backport bookmark to origin to open a PR from origin to upstream:release/1.29

Expected

$ jj git push --bookmark backport/202606 --remote origin

... should not rewrite local release/1.29, since that bookmark is not stale.

Actual

After the push:

• backport/202606 is pushed successfully
• Local release/1.29 changes to a different commit ID and becomes starred/stale

I checked the oplog but it shows only the push operation:

○  db49adf66011 ...
│  push bookmark backport/202606 to git remote origin
│  args: jj --color always git push --bookmark backport/202606 --remote origin
○  66f3bde762cc ...
│  rebase commit 8460ffc5bbbac67ef5ddb849ea0b940002e8d9d7 and descendants
│  args: jj --color always rebase --branch qq --onto release/1.29
○  5f2cfd1556cb ...
│  new empty commit
│  args: jj --color always new -r qq
○  42534cab4ade ...
│  fetch from git remote(s) origin,upstream
│  args: jj --color always git fetch --all-remotes

Before the push (at 66f3bde762cc), the status of my repo looked like this:

$ jj bookmark list --tracked
...
release/1.29: loluqymq 8882262e chore(deps): update `curl`
  @upstream: loluqymq 8882262e chore(deps): update `curl`

... also note the first and the last lines of the log view, the parent bookmark is not stale and the child bookmark is, so it feels like a push should suffice:

However after the push (at db49adf66011) it has become:

... so the whole history has been rewritten since and including release/1.29.

Environment

jj version: 0.42.0
OS: macOS v26.5.2
colocated repo: Yes

[rami3l]

I think I may understand why now. For the backport actually we need to do duplicate instead of rebase? The previous rebase "happened to" work because trunk is immutable, is that correct?

If that is the case then I might have confused jj's rebase with Git's rebase.

[rami3l]

Looks like there's more to it... Manually committing might still produce the same effect (that after pushing release/1.29 is rebased):