> In jj, everything rewrites the history (...)

Surely that isn't true, otherwise it would be completely unusable for auditing.

It's not true, in that sense. Commits in jj are basically the same as commits in git as far as mutability is concerned. But in jj you normally work with changes, rather than commits, and open changes are mutable (by altering which immutable commit they point to in the backing store). And there is effectively an append-only audit trail of these alterations (which is what makes `jj undo`/`jj redo` simple).

Some comments here are confusing the issue by saying ‘commit’ when they mean ‘change’ in the jj sense.

Re the grandparent comment, `jj describe` provides a change description, analogous to `git commit --amend --edit` in git terms.

it is true. some history is marked immutable by default; in git, everything is mutable by default and you have to add branch protection on the server side. (granted, you can change what is immutable in jj relatively easily, so you shouldn't ignore branch protection if you're using jj exclusively with a git repo, either.)

By default, if you push to main/master, it marks those commits as immutable (you can still force change). You can configure this to other branches.

But ... is it really that different from git? You can always rewrite history in git, correct?