[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.