Klabnik stakes his reputation on the claim that jj is 'both simpler and easier than git, but at the same time, more powerful.' He argues jj synthesizes the best of Git and Mercurial into something with fewer essential tools that work together more cleanly, while also enabling advanced workflows that are very difficult with Git.
The editorial argues that Git's conceptual model — staging area, index, HEAD, refs, reflog — is 'a stack of abstractions that accumulated over 20 years rather than being designed.' Jujutsu's elimination of the staging area removes an entire class of mistakes by making the working copy always a commit, which sounds alarming but proves practical.
Klabnik emphasizes that jj has a Git-compatible backend, meaning developers can use jj individually without requiring anyone else on their team to convert. He frames this as eliminating the downside of trying it: 'if it's not for you, you're not giving anything up.'
The editorial argues that 'winning doesn't mean the product is good — it means the product was good enough at the right time.' It notes that many developers who used both Git and Mercurial considered Mercurial the superior UX, but Git won on network effects, leaving room for a successor that combines better design with Git compatibility.
At least one HN commenter noted discomfort with edits being 'automatically committed,' reflecting the tension between jj's design philosophy and the staging-area workflow that Git users have internalized over years. This highlights a real adoption friction even if the new model is technically superior.
Steve Klabnik — Rust core team alumnus and technical writer behind "The Rust Programming Language" book — published a comprehensive tutorial for Jujutsu, the version control system that goes by `jj` on the command line. The tutorial landed on Hacker News and pulled 523 points, triggering the kind of detailed, experience-driven discussion that only happens when a tool has crossed from curiosity to genuine daily driver for a critical mass of developers.
Jujutsu isn't new. It started as a Google-internal project and has been open source for a couple of years. But Klabnik's tutorial marks something different: a respected practitioner staking his reputation on the claim that jj is "both simpler and easier than git, but at the same time, more powerful." That's the kind of statement that usually gets you laughed out of the room. The HN thread suggests he might be right.
Git won the version control wars a decade ago, and it won them decisively. But winning doesn't mean the product is good — it means the product was good enough at the right time. Every developer has a collection of Git horror stories: the detached HEAD that ate an afternoon, the rebase that turned into archaeology, the merge conflict on a file nobody actually changed. Git's conceptual model — staging area, index, HEAD, refs, the reflog as a safety net for the safety net — is a stack of abstractions that accumulated over 20 years rather than being designed.
Jujutsu takes a different approach. It synthesizes ideas from both Git and Mercurial (which many developers who used both considered the superior UX, even as Git won on network effects). The key design decisions:
No staging area. Your working copy is always a commit. This sounds alarming to Git users — one HN commenter noted the discomfort of edits being "automatically committed" — but in practice it eliminates an entire class of mistakes. There's no state where your changes exist in some limbo between tracked and committed. You're always working on a change, and you describe it when you're ready.
First-class conflict handling. In Git, conflicts are an emergency. In jj, conflicts are just data. You can commit conflicted state, rebase on top of it, and resolve when you're ready. This sounds minor until you've spent an hour resolving the same conflicts repeatedly during a complex rebase.
`jj absorb` — the feature Git users don't know they need. Multiple HN commenters called this out as a standout. When you have changes in your working copy, `jj absorb` automatically figures out which previous commit each change belongs to and moves it there. Forgot to update a config file three commits ago? `jj absorb` handles it without interactive rebase, without fixup commits, without any of the ceremony Git demands. One commenter called it "really handy when you forgot to make a change to some config file or .gitignore."
Simpler mental model, more powerful operations. jj has fewer core commands than Git, but they compose more cleanly. The HN discussion surfaced a telling workflow difference: one commenter noted that jj "wants me to start with the new and describe command" rather than Git's pattern of making changes and naming them at the end. This inversion is jarring at first but reflects a deliberate design choice — you're always working within a named change, not accumulating unnamed state.
The community reaction was notably split along experience lines. Developers who jumped in and used jj for a week tend to become converts. Those evaluating it theoretically raise valid concerns about the auto-commit behavior and the mental model shift. The most experienced commenter in the thread offered advice that cuts through the noise: "Don't think about git. Here's a workflow that'll get you through your daily usage." The point being that mapping jj concepts onto Git concepts is the wrong approach — it's a different tool that happens to be compatible.
The single most important thing about jj is the adoption story: it uses Git as its storage backend, which means you can use jj on any existing Git repository without anyone else on your team switching. Your commits look like Git commits. Your pushes go to the same remote. Your CI doesn't know or care. If you decide jj isn't for you after a month, you've lost nothing.
This is the opposite of how version control transitions usually work. Moving from SVN to Git required organizational buy-in, server migration, workflow changes for everyone simultaneously. Moving from Git to jj requires you to `jj git init --colocate` in an existing repo and start working. Your teammates keep using Git. You keep pushing to the same branches.
For teams evaluating jj more broadly, the practical considerations are:
IDE support is still maturing. Git tooling has had 15 years of integration work. VS Code, JetBrains, and every other editor speaks Git natively. jj support exists but isn't at parity. If your workflow is heavily GUI-driven, expect friction.
CI/CD pipelines don't need changes. Since jj's backend is Git, your pipelines, hooks, and automation continue to work. This removes the biggest organizational blocker to adoption.
The learning curve is real but front-loaded. The auto-commit behavior and the lack of a staging area require unlearning Git habits. Multiple HN commenters reported a day or two of discomfort followed by significantly faster workflows. The return on that investment compounds — operations that require careful multi-step sequences in Git (interactive rebase, cherry-pick chains, conflict resolution across branches) become straightforward single commands in jj.
Git isn't going anywhere. It's too deeply embedded in too many workflows, tools, and organizational processes. But jj doesn't need Git to go anywhere — it just needs to be a better interface to the same underlying data. The fact that a respected technical writer is now producing polished tutorial material, and that the HN response was overwhelmingly substantive rather than dismissive, suggests jj has crossed the threshold from "interesting experiment" to "tool worth evaluating." The last time a VCS generated this much practitioner enthusiasm, Git was replacing Subversion. The difference this time is that you don't have to convince anyone else to switch.
Does JJ really prefer for me to think backwards? It wants me to start with the new and describe command, but with git I first make the changes and name the changeset at the end of the workflow.I also often end up with in a dirty repo state with multiple changes belonging to separate features or abst
I'm giving jj a try but one aspect of it I dislike is edits to files are automatically committed, so you need to defensively create empty new commits for your changes. As in, want to browse the repo from a commit 2 weeks ago? Well if you just checkout that commit and then edit a file, you'
The last paragraph might be the most important one:> There's one other reason you should be interested in giving jj a try: it has a git compatible backend, and so you can use jj on your own, without requiring anyone else you're working with to convert too. This means that there's n
One of my favorite jj features is "jj absorb".For each change you've made in the current revision, it finds the last commit where you made a change near there, and moves your changes to that commit.Really handy when you forgot to make a change to some config file or .gitignore. You ju
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
A lot of the discussion focuses on differences from git and how it uses the git storage strategy under the hood. Honestly, I think you should just ignore all of that. Don't think about git. Here's a workflow that'll get you through your daily usage:On a clean repo: $ jj The working co