For me, jj is better than git because it has achieved something of a holy grail: it is both simpler and more powerful, at the same time. It achieves this by hav

For me, jj is better than git because it has achieved something of a holy grail: it is both simpler and more powerful, at the same time. It achieves this by having more cohesive primitives. Take the index. I love(d) git’s index. It is a powerful way to build up focused commits. Jj does away with the index, yet gives you equivalent power. How? Because instead of a separate index concept, jj has a special name for a commit representing the index: @. Files are (by default) automatically tracked and included in @. Just like how you’d git add -p, you create a new commit for your work, then create a commit on top of it. As you work, @ gets built up with your code, and when you’re ready, jj squash (with various flags or paths to control exactly what gets added) to move them into your parent, “real” work commit. So if it’s the same, why is it better? Because we’ve reduced the number of states: instead of dirty, staged, and committed, you just have committed. And with that, commands are simpler: no distinction between —hard or —soft for something like git reset, everything just operates on committed state. This means you can bring the full set of tools to manipulate commits to bear on your index! The same goes with stashing: because heads are allowed to be detached, to use the git terminology, we don’t need a special stash concept: create a new commit that’s forward of where you’re working to “stash” your changes in there until you need them. These are two simple examples, but it’s really about how everything fits together into an extremely powerful and cohesive tool.