How to prevent tracked bookmark from following rewritten history?

[jcornaz]

I just realized (with horror) that if track a bookmark and someone force-push that remote git branch to a different commit (that is not a descendant of the previous commit), the next time I run jj git fetch my bookmark will happily follow the new commit, potentially making me lose the old one. And if yes, I could jj undo or eventually find it back, the thing is I may miss that it even happened in the first place before it's become way to hard (if possible at all) to recover.

Is there a way to prevent that behavior? If not, that make the bookmark tracking way too dangerous, what would then be the recommended workflow to push to a git remote without tracking bookmarks?

[MLuc24]

The scenario is less dangerous than it looks, because jj only moves the local bookmark silently in the case where you have nothing at stake there. From docs/bookmarks.md:

jj will then update main@origin to the new target. If main@origin is tracked, jj will also apply the change to the local bookmark main. If the local target has also been moved compared to main@origin (probably because you ran jj bookmark set main), then the two updates will be merged. If one is ahead of the other, then that target will become the new target. Otherwise, the local bookmark will become conflicted.

So the branching is on whether your local bookmark has moved since the last fetch:

• It hasn't → you were sitting exactly where the remote was, so following the force-push loses nothing that was yours.
• It has, and the two aren't ancestor-related → that's exactly your feared case, and it produces a conflicted bookmark rather than a silent overwrite. Conflicted bookmarks are loud: they show up in jj bookmark list, and commands that need an unambiguous target refuse to run until you resolve it.

Which means the case you'd actually want protection from is the one that already has it.

On the "I might not notice" part — that's what the operation log is for, and it covers this even in the silent case. Every fetch is an operation, so jj op log shows exactly what moved, jj op diff shows the before/after refs, and jj undo puts it back. The old commit isn't unreachable in the meantime either; it stays in the repo until garbage collection, and the op log keeps a reference to it, so "find it back" is jj op log rather than reflog archaeology.

If you still want the guarantee rather than the audit trail, untracking is supported and is the documented way to do it:

jj bookmark untrack <bookmark>@<remote>

After that, subsequent fetches of that remote will no longer move the local bookmark to match the position of the remote bookmark.

You keep pushing with jj git push --bookmark <name>; you just stop having fetch move things underneath you, at the cost of doing the "is my bookmark behind?" comparison yourself against <bookmark>@<remote>.

For what it's worth I'd only reach for that on a remote where force-pushes to shared bookmarks are routine. Elsewhere the conflict behaviour plus jj op log is the better trade, since untracking means you also stop getting told when the remote moved at all.

[jcornaz]

Thank you to much for the detailed explanation.

However, I have to admit, I am left unsatisfied...

• It hasn't → you were sitting exactly where the remote was, so following the force-push loses nothing that was yours.

First, I do not want to inadvertently loose things, even if they are not "mine".
Second, don't find that much reassuring. If I commit and push, and then someone else force push to a different commit, then next time I fetch (unless I added additional work in the meantime) I lose my old commit. This is precisely what I do not want to happen.

[...] it stays in the repo until garbage collection [...]

Therefore if I realize after garbage collection, it might be too late.

You keep pushing with jj git push --bookmark <name>; you just stop having fetch move things underneath you, [...]

jj git push --help says that jj git push --bookmark <name> will automatically start tracking the bookmark:

-b, --bookmark
Push only this bookmark, or bookmarks matching a pattern (can be repeated)

If a bookmark isn't tracking anything yet, the remote bookmark will be tracked
automatically.

By default, the specified pattern matches bookmark names with glob syntax. You can
also use other string pattern syntax.

[jcornaz]

What I wish for is an equivalent to git config pull.ff only, which basically only update my local branch if it can be "fast-forwarded". (note that anyway by default git would have created a merge commit, so I wouldn't have lost anything anyway)

This is what I had in my git config for ages, and I just took it for granted. When I started to use JJ I didn't realize I lost that :-/

[MLuc24]

You're right on the push point and my suggestion doesn't survive it — if --bookmark re-establishes tracking, then "untrack and keep pushing that way" quietly undoes itself on the next push. Scratch that part.

And pull.ff only is a much better statement of what you want than anything I offered, so let me answer that directly: jj has no equivalent, and it isn't a missing knob so much as a different model. jj doesn't do pull-with-fast-forward-or-merge; it does a three-way merge of the ref targets themselves, described in design/tracking-branches.md as "remote changes are merged into the local counterparts", with the last-imported position as the base. When your local hasn't moved, that merge has only one changed side, so it resolves to the remote's new target. There's no fast-forward test anywhere in that path to make strict, which is why there's no setting to make it strict. The config surface around fetch is only git.fetch, and that just selects which remotes to contact.

I'd also drop the "loses nothing that was yours" framing — you're right that it's not the point. Someone else's commit disappearing from under you is still a loss, and "you can recover it" is a worse property than "it can't happen".

One thing I did get wrong in the pessimistic direction, though, and it matters for the GC worry. Displaced commits aren't sitting in a repo waiting to be swept — they're referenced by the fetch operation itself, and jj util gc won't touch commits an operation still references:

/// Run backend-dependent garbage collection.
///
/// To garbage-collect old operations and the commits/objects referenced by
/// them, run `jj op abandon ..<some old operation>` before `jj util gc`.

So losing it for real takes two deliberate commands, in order, neither of which runs on its own. "I might notice too late" would require you to have abandoned that operation range yourself first. That's a real safety net rather than a race against a background process — it just isn't prevention, which is what you asked for.

Given that, I think the feature request is the right move rather than a workaround, and it's worth framing exactly as you did here: a fetch policy that refuses to move a tracked local bookmark when the new target isn't a descendant of the old one, leaving it conflicted (or simply not moved) instead. That's a small, well-defined ask that fits the existing conflict machinery, and "I had pull.ff only set for years and didn't realise I'd lost it" is a strong motivation to put in it.

[josephlou5]

I think you can set git.abandon-unreachable-commits = false to get the behavior that jj git fetch does not abandon your old remote bookmark once it sees that it's moved to somewhere else. Does that work? (This also means, however, that if you merge a PR and the bookmark is deleted on the remote and you don't care about it anymore, jj git fetch will still keep it around, and you'll have to abandon it manually.)

https://docs.jj-vcs.dev/latest/config/#abandon-commits-that-became-unreachable-in-git