What helped me understand jj was concept of Changes against commits. Commits are immutable checkpoints, snapshots of the work done. Changes are mutable sets of,

What helped me understand jj was concept of Changes against commits. Commits are immutable checkpoints, snapshots of the work done. Changes are mutable sets of, well, changes. Of course, commits are used by the git backend anyway, I'm talking about conceptual level. The most notable mental shift is that you create a Commit (git add && git commit) after you are done, whereas you create a Change (jj new) before starting working on it, and you don't need to explicitly save it after, you bookmark and push it, or start working on a new change. Consequently, there is no distinction between working directory, index and the commit history. You only have one concept - Change, and you edit them however you wish, whether it's newly created change, or a very old one, or a merge, or whatever else From my experience, you should be able to fit any git worklow in this model: - Anything that requires creating commits is jj new, merge is also jj new. - If you wish to only save part of the changes (like git add -p) you call jj split. - git squash is jj squash - amend is also squash - rebase is automatic (jj edit or jj new --{after,before}) - git stash is obsolete (everything is saved anyway, just run jj new) - etc.