[password4321]

> I also like the ability to checkout an old commit, make a change to it, then have all my more recent commits automatically get rebased (not exactly what happens, but the analogy works)

Can anyone comment on how Jujutsu "rebases" multiple commits at once vs. git prompting each one be signed (eg. touch Yubikey), and how it looks afterward in git?

[saghm]

One of the main innovations in how `jj` works (in my opinion at least) is that has a concept of "immutability" for commits, which if I recall correctly is configurable with an arbitrary filter in the config, but the default (which I've never messed with personally) essentially considers commits in tracked branches from remotes to be "immutable", meaning that anything purely local is "mutable". When you run a command to try to change any immutable commits, it will refuse unless you manually opt-in with `--allow-immutable`. This makes it super easy to clean up the commit history from local development without having to worry about accidentally putting stuff in a state where there will be conflicts when you try to sync the changes with a remote later.

I think what they're the parent commenter is referring is being able to make changes to older "mutable" commits without having to do a rebase. I'm not sure I find the description of this as being similar to an "automatic rebase" super helpful personally; the way I'd personally describe it is being able to do the equivalent of "git commit --amend" on any commit with a built-in safety check to prevent this from accidentally modifying commits pushed to remote branches that you need to explicitly override if you want to ignore it.

[justinpombrio]

> the default (which I've never messed with personally) essentially considers commits in tracked branches from remotes to be "immutable", meaning that anything purely local is "mutable"

The default for what's immutable is actually `main` together with untracked remote branches [1]. I agree that what you suggested should be the default though. You can change it by adding this line to your `jj` config:

  [revset-aliases]
  "immutable_heads()" = "builtin_immutable_heads() | remote_bookmarks()"

(To edit your jj config, run `jj config edit --user`.)

[1] https://jj-vcs.github.io/jj/latest/config/#set-of-immutable-...

[sunshowers]

So the reason this isn't the default is that often you'll be amending and force pushing tracked remote bookmarks.

There are several use cases for bookmarks/branches that are a bit muddled, which suggests a deeper theory of bookmarks that should inform the user experience. One of the Jujutsu developers had a neat post on the Discord [1] talking about how "bookmarks must be data-flow edges: think mutability, variance, polarity, etc." This sounds generally right to me, though turning this into a fleshed-out theory and then into a good user experience is a bit of a daunting challenge.

[1] https://discord.com/channels/968932220549103686/132711440887...

[sunshowers]

(Commit mutability separation, like many of jj's other features, was originally implemented in Mercurial.)

[saghm]

Good to know! I guess the "innovative" part was being able to apply these semantics on top of git without breaking compatibility.

[sunshowers]

Yeah. In Mercurial the set of immutable heads is state that's stored in the repository. In Jujutsu this is done via a revset, which is a really clever approach.

[stouset]

If you require a physical touch for every sign operation on your YubiKey and you sign all your commits, you are going to have a bad time with jujutsu. That is somewhat unavoidable. If you are open to caching your credentials and only requiring a physical touch once every so often, this pain goes away entirely. If a physical touch for every sign is nonnegotiable, this probably isn't going to be a tool that works for you.

Jujutsu rebases multiple commits at once almost exactly the same way git does it. The three huge improvements are: 1) rebases happen automatically for descendent commits when their parents are modified, 2) rebases happen entirely in-memory and so don't require filesystem operations, which is an enormous performance benefit, and 3) rebase conflicts are a first-class citizen and doesn't require interrupting everything to drop you into a wedged rebase so you can fix it.

The third aspect combined with the first one means you can just jump to where a rebase conflict occurred, fix it, and… you're done. All the children are fixed for you automatically. If there were more, you can fix them up in the order that makes sense to you and you don't need to completely finish before being able to jump around elsewhere in the repo.