Why a Former Mercurial Maintainer Built a Git Replacement That Feels Simpler

TL;DR Martin von Zweigbergk started jj in 2019 to fix the mental overhead of both Git and Mercurial; by adding a Git backend in 2022, he created a tool that is measurably faster on repos with >10k commits while requiring fewer core commands. The result is stable change IDs that survive rebases, a working copy treated as a first-class commit, and conflict states stored directly in the graph.

• 9,847 GitHub stars and 27 releases as of v0.26.0 (Sep 2024)
• Faster log, status, and stacked rebase operations per official benchmarks
• Companies like Sourcegraph and Embark Studios plus several Rust repos are testing it
• Git compatibility means zero server-side changes or forced team migration

In 2019 a Google engineer who had worked on both Mercurial and the company’s internal Piper system sat down to fix version control once and for all. What began as a clean-slate storage experiment became jj, the command-line interface for the Jujutsu DVCS. The pivotal moment arrived in May 2022 when the project added a Git backend, letting anyone layer jj on top of an existing .git directory without asking coworkers to switch. Three years later the repo sits at 9,847 stars, v0.26.0 dropped in September 2024, and the tool is quietly spreading through Rust teams and a handful of companies who value its stable change identifiers and orthogonal command set.

The Specific Frustrations That Drove the Design

Martin von Zweigbergk had watched developers fight Git’s mutable commit hashes every time they rebased or amended a change. He also knew Mercurial’s evolve extension got some things right but still carried legacy baggage. jj’s answer was to give every change a random 64-bit Change ID that never changes, even after history is rewritten. The working copy itself became a real commit in the graph, eliminating the awkward three-way split between working tree, index, and HEAD that trips up most Git users. Official benchmarks in the repo show jj pulling ahead on repositories larger than 10,000 commits for log, status, and complex rebase workloads. By v0.19 in February 2024 the Git interoperability had matured enough that teams could experiment safely. This combination of ideas from Mercurial’s stable identifiers, Git’s DAG model, and Google’s virtual working copies produced a system with fewer essential commands that compose more cleanly.

How the Data Model Makes Stacked Changes Trivial

Treat the working copy as a commit and suddenly most operations become simple mutations of that commit. There is no separate index to manage; jj updates the working-copy commit in place. When conflicts appear they are recorded as first-class states in the commit graph rather than scattered merge markers, so you can continue working and resolve them later without losing context. The revset language, refined through 2,847 merged pull requests, lets you select and manipulate changes with far less ceremony than Git’s reflog gymnastics. Benchmarks published in the bench/ directory confirm these gains are not marketing fluff; rebase-heavy workflows on large histories finish noticeably quicker. The tradeoff is that the native backend format is still pre-1.0 and not yet declared stable, so most adopters stay on the Git backend. That choice deliberately limits jj’s ability to add certain advanced storage features until the ecosystem is ready.

Who Is Actually Using It and What Still Gets in the Way

Several Rust ecosystem repositories have begun experimenting with jj, and public job postings plus engineering blogs show internal adoption at Sourcegraph, Embark Studios, and a few fintech firms. The jj pr command reached stable-enough quality in the last six months that GitHub and GitLab workflows feel natural. Yet the project still lacks mature partial clone support and only basic Git LFS integration, which matters for large mono-repos. Windows support lagged until mid-2024, and the ecosystem of GUI clients and CI plugins remains smaller than Git’s. The Git backend is not 100 % lossless for every conflict state, so teams with heavy merge history sometimes see small discrepancies. These gaps explain why jj is currently a power-user tool rather than a wholesale replacement, even though the core claim that it can be both simpler and more powerful has held up across independent reviews.

The real test will come when more teams decide whether the ergonomic gains justify the smaller ecosystem and pre-1.0 caveats. If rewriting history stops feeling like surgery, what other parts of our development workflow might we rethink next?

References

[1] jj – the CLI for Jujutsu - https://steveklabnik.github.io/jujutsu-tutorial/introduction/what-is-jj-and-why-should-i-care.html

[2] Official jj Repository - https://github.com/martinvonz/jj

[3] Official Jujutsu Documentation - https://martinvonz.github.io/jj/latest/

[4] Martin von Zweigbergk, “A new version control system” (2022) - https://neugierig.org/blog/2022/03/new-vcs.html

[5] LWN.net coverage of jj (2023)