Klabnik's tutorial emphasizes that jj uses Git repositories as its default storage backend, meaning you can `jj git clone` and push to the same remote your teammates use with plain Git. This framing positions interoperability as the decisive feature — you don't need to convince your team or migrate your repo, eliminating the collective-action problem that doomed Mercurial, Darcs, and other alternatives.
The editorial highlights that jj's Git compatibility means individual developers can adopt it unilaterally without team buy-in. This is framed as the structural reason jj has a realistic path to traction where previous Git competitors failed — it competes on workflow, not on repository format.
Klabnik's tutorial walks through jj's model where the working copy is always automatically snapshotted as a commit, eliminating Git's liminal state where changes can be lost. He argues this isn't just a convenience but a rethinking of core workflow assumptions, making the staging area obsolete since most experienced developers just `git add -A` before every commit anyway.
The editorial notes that the tutorial hit 500+ points on Hacker News, placing it in roughly the top 0.5% of submissions, and observes that version control tutorials almost never generate this level of engagement. This is presented as evidence that latent frustration with Git's complexity has been building and jj is crystallizing it into actual momentum.
Submitted the tutorial to Hacker News where it generated 511 points and 445 comments, an extraordinary level of engagement for a VCS topic. The volume of discussion suggests the community was primed for a serious Git alternative conversation.
The editorial emphasizes that jj was created by Martin von Zweigbergk at Google, where it's been used alongside Google's existing monorepo tooling. Combined with being written in Rust and MIT-licensed, this positions jj as production-grade infrastructure with corporate backing rather than an experimental side project.
Steve Klabnik — Rust community veteran and co-author of *The Rust Programming Language* — published a comprehensive tutorial on jujutsu, the version control system that goes by `jj` on the command line. The tutorial hit Hacker News and climbed past 500 points, a score that puts it in roughly the top 0.5% of HN submissions. That's notable not because tutorials never go viral, but because version control tutorials almost never do. The last time a VCS post generated this much HN engagement, it was about Git itself.
jujutsu was created by Martin von Zweigbergk at Google, where it's been used internally alongside Google's existing monorepo tooling. It's written in Rust, MIT-licensed, and — here's the part that matters — it uses Git repositories as its default storage backend. You don't migrate your repo. You don't convince your team. You `jj git clone`, do your work with `jj` commands, and push to the same remote your teammates are pulling from with plain Git.
The tutorial walks through jj's mental model from scratch, which is necessary because jj doesn't just reskin Git commands. It rethinks the core workflow assumptions that Git inherited from its 2005 origins.
### The Working Copy Problem Git Never Solved
Git has an uncommitted-work problem. Your working directory is a liminal space — changes exist there but aren't tracked, recoverable, or referenceable until you explicitly stage and commit them. Every Git user has lost work in this gap. The index (staging area) was supposed to help, but in practice it's a source of confusion for beginners and a tax on experienced developers who habitually `git add -A` before every commit anyway.
jj eliminates this entirely: your working copy is always automatically snapshotted as a commit. Every state of your working directory is a node in the commit graph. There is no staging area. If your laptop catches fire mid-refactor, every file state you've touched is recoverable from the operation log. This isn't autosave bolted onto Git — it's a fundamental architectural choice that cascades through the entire UX.
### First-Class Conflicts Change Everything
In Git, a merge conflict is a stop-the-world event. Your repo enters a conflicted state, and you cannot do anything else — no committing, no branching, no shelving the conflict for later — until you resolve every conflict marker. This is fine for simple merges. It's miserable for complex rebases across dozens of files.
jj treats conflicts as data, not as errors. A conflicted file can be committed, pushed, rebased, and resolved at any time — conflicts are just another state a file can be in. You can rebase a branch, see that three files conflict, fix the one you understand, commit, and come back to the other two tomorrow. You can even push a conflicted commit to a shared branch for a colleague to help resolve. This is genuinely new territory for mainstream VCS tooling.
### The Operation Log Is the Undo Git Should Have Had
Git's `reflog` is a partial undo mechanism that only tracks reference changes. If you want to undo a rebase, you need to find the right reflog entry, understand the commit graph state at that point, and `git reset --hard` to it — which itself is a destructive operation. Most developers don't trust it.
jj's operation log records every operation (commit, rebase, merge, branch move) as an immutable entry. `jj undo` reverses the last operation. `jj op log` shows you every state your repo has been in. `jj op restore` takes you back to any previous state. This is version control for your version control — and it makes previously terrifying operations like rebase, squash, and split trivially reversible.
### Why This Tutorial Hit Different
Klabnik's tutorial succeeded because it addressed the real adoption barrier: jj's concepts are unfamiliar enough that the `--help` text doesn't suffice. Git users need a guided mental model shift. Key concepts the tutorial covers:
- No branches by default. jj uses anonymous "changes" identified by short IDs. You can add bookmark names (similar to branches) when you need them, but the default workflow is branchless. - Revset expressions. Instead of Git's ad-hoc revision syntax (`HEAD~3`, `main..feature`), jj uses a composable query language for selecting commits. Think SQL for your commit graph. - Automatic rebasing. When you amend an earlier commit, jj automatically rebases all descendants. No manual `git rebase --onto` chains.
The 500+ HN score matters because it's a signal of pent-up demand. Developers have been complaining about Git's UX for fifteen years. Tools like `git-branchless`, Sapling (Meta), and GitButler have all tried to improve the experience. jj is the first one that's gaining traction without requiring you to abandon the Git ecosystem.
You can try it today with zero team coordination. Because jj uses Git repos as its backend, adoption is a personal choice. Install `jj`, clone your repo, do your work. Your commits land as normal Git commits. Your teammates don't need to know or care. This is the single biggest advantage jj has over every previous Git alternative — there's no migration, no server changes, no team buy-in required to start.
The learning curve is real but front-loaded. If you've internalized Git's mental model over years, jj will feel wrong for about two weeks. The lack of an index, the automatic working-copy commits, the branchless-by-default workflow — all of it contradicts Git muscle memory. But the reports from developers who've pushed through are consistent: once the new model clicks, going back to raw Git feels like voluntarily putting on a straitjacket.
Watch the ecosystem, not just the tool. jj's long-term viability depends on three things: IDE integration (VS Code and JetBrains plugins are in early stages), CI/CD compatibility (most CI systems assume Git, and jj's co-located mode handles this), and hosting platform support (GitHub, GitLab, etc. all work today because jj pushes standard Git refs). The Git-backend strategy means jj doesn't need the ecosystem to adopt it — it needs the ecosystem to not actively block it, which is a much lower bar.
jj sits at an interesting inflection point. Google internal usage provides stability and resources. The Git-compatible backend removes the cold-start adoption problem that killed every previous Git alternative. And now a high-quality, community-driven tutorial is lowering the learning curve. The question isn't whether jj is technically superior to raw Git for most workflows — the tutorial makes that case convincingly. The question is whether enough developers will invest the two weeks of discomfort to find out. If the HN response is any signal, the answer is shifting toward yes.
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