I have to work with Gerrit, which requires amending existing commits after they've been pushed to the remote branch to address comments. I'll frequently have lots of commits I'm working on above the commit in review. Along with a couple other branches. Every commit also has to compile and pass tests. I'll frequently go git rebase -i --autosquash paired with git fixup. I've made mistakes before that are hard to untangle. With jj it's just jj edit .

Or if I want to insert a commit between two others it's just jj new -A to create a new commit after the change id (but BEFORE the previous change that was after the commit). With git I'd need to commit then rebase, put it in the right slot and recompile, rerun tests, re-edit. If I work on a branch I'd need to rebase, possible merge conflicts. jj just puts me on that commit then helps me manage merge conflicts going up. It's fewer commands focused on what I want to do and less on the tree like git.

For me, I am and have been using it in two different situations:

• at work, when I was writing tests and documentation for an old numeric library somebody else wrote, and tests for an OS abstraction layer for real-time systems. With git, I used to use worktrees to keep and extend the documentation in another branch. I found that in jujutsu, a worktree was not needed because it was easier/quicker to work on different branches (or series of changes) than in git.

• at home, in two leisure projects written in Guile and Rust. Here, I wanted a clean/tidy history including for the parts that were developed in an experimental manner. With the git CLI, that would have required heavy use of rebase and so on. I would have used the Magit git interface, but most likely I would have avoided most of the tidying up because of the extra effort1. With jujutsu, this was much less effort - it was fun.

Currently, I don't use jujutsu at work because I am taking over an old legacy project from an almost-retired developer and he is still helping me explaining things and looking at his last changes in the maintenance branch. I don't want to burden him with a new tool as his time is very scarce. (But jujutsu is perfect for things like "throwaway refactoring" of legacy code, so I will for sure use it in the future).

BTW, I was using git CLI since 2008 or so, and Emacs/Magit since about 2017, full time. But I often needed to look up more complex git functions in the man pages.

squash exists but it squashes commits.

The rebase command is a bit more flexible but a key difference is handling of conflicts: They represent as regions with conflict markers in the conflicted text regions and all following commits/changes, and they disappear once the conflict has been resolved. No weird interim stated and git rebase --abort. If you want the old state back, you only need to do jj undo and that's it.