An unintentional force push: what I've learned after my first day with jj

[peterbb]

Hey! I tried jj for the first time today, and I really like the experience. :) I did unintentionally do a not-fast-forward push to a remote branch. No harm done, but I would have expected at some point to be asked if I really wanted to do that. So I recreated that situation in a test a repo to learn more and to create a challenge for myself.

While jj branch move will refuse to move backwards or sideways without --allow-backwards, running the following causes a "force" push, which is what I did earlier today:

jj new -m "new feature" main
echo "initial code" > file.txt
jj branch create shared_branch
jj git push
echo "updated code" > file.txt
jj git push

My guess is that the default behavior allows this because it would not be such a destructive action with a native jj backend and because it's appropriate for other workflows.

First I went looking for a way to make jj git push ask me if I really wanted to do that. I didn't find it, but I did find a much more interesting challenge: What if I had noticed the problem before I did the final push. What would I do to not lose my changes, but still do a forward push?

First I tried jj new -m "my update"; jj restore --from shared_branch@origin --to @-, with the result that my change was gone from @ and @- had the wrong commit id anyway. The only solution I've found so far is to use jj op undo (or jj op restore), then jj new, and finally jj restore --from <commit id with change>.

That solves the challenge as stated above. But what if I had done lots of unrelated stuff in the repo before I noticed the problem. Then jj op restore would undo all those operations, and I would have to manually redo the operations. Right? So I'm still wondering if there is some way to set the commit id for a change.

Back to the question of how to make jj git push ask me if I really wanted to force push: Even though I had read the documentation about immutable_heads, I didn't immediately realize that that was what I was looking for. It seems like the following config is what I need (I've not tried it in anger yet):

"immutable_heads()" = "trunk() | tags() | remote_branches()"

It's so obvious in hindsight, so I started to wonder how I missed it. Here is my theory:

The documentation says

Set of immutable commits

You can configure the set of immutable commits via revset-aliases."immutable_heads()".

When I read this the first times, I probably had too much of a git-mindset: 💭 All commits are immutable! 💭 My issue is related to moving the branch "pointer", not commits. 💭 There is nothing about fast-forward or force here. 💭 It was only after getting more intimate with jj while exploring the challenges above, that I read the documentation from a different perspective, and saw the solution.

It also seems to me that the documentation uses the terms "changes" and "commits" inconsistently. Based on how I understand the tutorial, the documentation about immutable_heads should talk about immutable changes, right?

While the above is more of a story, I wonder:

• Would it be a good idea to make an entry in the FAQ where the above problem formulated from a git perspective? Something like: "How do I make jj git push require --force for force / not fast-forward pushes? Answer: You can't do exactly that, but by setting immutable_heads() [as described above] you won't get into that situation, unless you have used the --ignore-immutable earlier.
• Is the terminology regarding changes, commits and revisions settled? If it is, I guess at least the inconsistency above could be fixed.

I can at least make a PR for the first point.

[martinvonz]

• Would it be a good idea to make an entry in the FAQ where the above problem formulated from a git perspective? Something like: "How do I make jj git push require --force for force / not fast-forward pushes? Answer: You can't do exactly that, but by setting immutable_heads() [as described above] you won't get into that situation, unless you have used the --ignore-immutable earlier.

By the way, we include untracked_remote_branches() in the default immutable_heads() revset since 0.20.0 (#4083). So that should at least reduce the risk of accidental force-pushing, because now it only happens if you had a local branch tracking the remote branch.

We could add a config option to require --force (or maybe --allow-rewrites). Maybe it's even a good idea to make that the default since force-pushes are disallowed in many common Git workflows. Around here should be a good place to add such a check. But you may want to give others a day or two to comment. Maybe I'm missing a reason we should not have such a config. It's of course inconvenient for users with a workflow that allows rewriting, and maybe it's not really needed after the PR I mentioned above?

• Is the terminology regarding changes, commits and revisions settled? If it is, I guess at least the inconsistency above could be fixed.

I think we've concluded that we prefer "revisions" over "commits", but I'm not sure that means we would want a PR that replaces all uses of "commits". A "change" is the thing identified by a "change id", so it's not a synonym (at least that's how I see it - I think several people consider "change" another synonym for "revision"/"commit").