Why look at Jujutsu at all

Part 1 of 9 in a series on learning jj in colocated mode.

Git works. Fifteen years in, the ecosystem around it is enormous and every teammate already knows it. That’s a high bar for anything claiming to replace it, and Jujutsu (jj) isn’t trying to clear that bar in one jump - it’s trying to sit on top of the same Git repositories everyone already has, so adopting it is a personal choice rather than a team migration.

A few things about it are worth the look on their own merits, independent of any philosophical preference for a “better” version control model:

• No staging area. Every command snapshots the working directory first. There is no moment where git status shows a pile of unstaged and staged changes and I have to remember which is which.
• History editing without ceremony. jj edit <commit> lets me fix something three commits back directly, no git rebase -i, no detached HEAD, no “please don’t lose my work” anxiety. Lesson 5 covers this in full.
• An operation log broader than a reflog. jj undo reverts the last thing I did to the repository, whatever it was - not just the last ref update.
• Conflicts are just data. A conflicted rebase doesn’t stop and demand resolution before I can do anything else. It produces a commit that records the conflict, and I deal with it whenever I want.

None of that requires abandoning Git. Colocated mode - a single working directory backed by both .jj and .git - means the actual object database underneath is still plain Git. Every teammate who has never heard of jj, every CI pipeline, every Git GUI keeps working exactly as it did before. That’s the property that makes this worth trying at all: the downside of a bad fit is close to zero, because nothing about the shared, visible parts of the repository changes.

The plan for this series: installation, the mental model, how the thing is actually built underneath, making the terminal output pleasant to look at, then the actual daily workflow and how it meets Git on the way out to a remote.