Jujutsu (jj): a Git-compatible VCS with an operation log and automatic rebase

What Jujutsu replaces, and who feels the difference

Jujutsu is a version control system written in Rust. The README describes it as designed from the ground up to be easy to use, for newcomers and experienced users alike, whether the project is new and solo or a large codebase with a long history and many contributors. It is not a Git wrapper in the thin sense. Internally it separates the user interface and the version control algorithms from the storage system that serves content. Today that storage layer is a Git repository, which is what makes the tool compatible with Git-based tooling, but the abstraction is deliberate: the README names Mercurial, Breezy and Google's Piper/CitC as examples of other physical backends the design could serve.

The people who get the most from it are those who rewrite history constantly. Amend a commit and every descendant is rebased automatically. Resolve a conflict in one commit and the resolution propagates through descendants. The README compares the effect to a transparent combination of git rebase --update-refs and git rerere, supported by design rather than bolted on. If your workflow is a stack of small patches that you keep reshuffling, that is the target use case. If you commit once a day to a long-lived branch and never touch history, most of the design is idle machinery.

Working-copy-as-a-commit and the missing staging area

The single design choice that shapes everything else is that the working copy is a commit. Changes to files are recorded automatically as normal commits and amended on every subsequent change. The README calls this a snapshot design and claims it simplifies the user-facing data model, because commits become the only visible object, and subsumes Git's stashes and index in one stroke.

There is no staging area. The README's Git comparison page is linked under the phrase no explicit index. For someone used to git add -p to carve a commit out of a messy working tree, that absence is the first thing to notice. The workflow shifts from selecting hunks before committing to committing everything and then splitting or squashing afterwards, which is why the history-rewriting primitives matter so much. They are not a convenience feature on top of the model. They are the mechanism that makes the model usable.

Conflicts are treated the same way. The README states that Jujutsu keeps track of conflicts as first-class objects, in the same way commits are first-class, whereas Git treats a conflict as a textual diff. The README is careful about the comparison: it says the approach is not as rigorous as Darcs, which is based on a formalized theory of patches rather than snapshots. What the design buys is that many forms of conflict resolution can be performed and propagated automatically. What it does not buy is a proof that any resolution is correct.

The operation log, and why undo is a repository feature

Jujutsu records every operation performed on the repository, including commits, pulls and pushes. The README frames this as making questions like what just happened and how did I end up here easier to answer, particularly when you are helping a coworker debug their repository rather than your own. Because the operations are recorded, you can undo a mistake.

This is a different layer from commit history. Commit history tells you what the code looked like. The operation log tells you what the tool did, in what order, which is the information you actually want when a repository is in an unexpected state. It also gives a plausible answer to a question Git users tend to handle with reflog archaeology and guesswork.

The README is candid that the ergonomics here are not novel in computing generally: it jokes that version control has finally entered the 1960s, with a link to the history of undo. That self-awareness is worth taking at face value. An operation log is a well-understood idea; the interesting part is that it is wired into a VCS with an automatic rebase model, so undoing an operation also has to unwind the rebases it triggered.

Getting it running: install, init, and the config surface

The README points to a dedicated installation and setup page at docs.jj-vcs.dev/latest/install-and-setup and a tutorial at docs.jj-vcs.dev/latest/tutorial. Those pages, not the README, carry the concrete commands, and the README itself does not reproduce them. That is worth stating plainly rather than guessing at a package name.

What the material does establish is the shape of the setup. The default storage backend uses Git repositories for physical storage, so a jj repository sits on top of a Git repository rather than replacing it. The README also states that only commits and files are stored in Git, while bookmarks (branches) and other higher-level metadata are stored in custom storage outside of Git. That sentence is the one to keep in mind before you initialize anything, because it determines what other tools can and cannot see.

The configuration surface is described in two places. Output formatting is handled by a template language that the user can configure, which the README credits to Mercurial and Sapling influence. Commit selection uses a revset language, also Mercurial-inspired. Both are config-level concerns: revsets are how you name sets of commits on the command line, and templates determine what gets printed. Neither is documented with concrete syntax in the README, so the revsets page and the template documentation are the places to look before writing anything into a config file.

The concurrency story is the most interesting claim, and the most qualified

The README makes an argument that is unusual for a VCS. Filesystems like Dropbox and tools like rsync assume that local filesystem operations are atomic, serialized, and non-concurrent with respect to other reads and writes. The README states that this assumption does not hold on distributed filesystems, or when concurrent file copies happen while lock files are held. That is the standard explanation for why syncing a Git repository through a file-sync service tends to end badly.

Jujutsu is instead described as designed to be safe under concurrent scenarios. Simply using rsync or Dropbox and then using the resulting repository should never leave it in a corrupt state. The worst outcome the README promises is that conflicts between local and remote state are exposed, leaving you to resolve them. That is a meaningfully weaker guarantee than correct merging, and it is stated as such.

Then comes the qualification. This feature sits under a warning block in the README, alongside a small set of others. The warning says these features are available for use but experimental, and that they may have bugs, backwards incompatible storage changes, and user-interface changes. So the concurrency safety is a design intention with an explicit caveat attached, not a settled property. If you are considering putting a jj repository in a synced folder, the README's own warning is the first document to read, followed by the linked concurrency page under docs.jj-vcs.dev/latest/technical/concurrency.

Where jj is the wrong tool

The metadata split is the sharpest limitation and it is easy to underestimate. Commits and files live in Git, so Git-based tools can read them. Bookmarks and other higher-level metadata live in custom storage outside Git. The README says the project hopes it works with your favorite Git forges, phrasing that is closer to an aspiration than a guarantee. If your workflow depends on a forge reading branch state, on pull request automation keyed to branches, or on any tool that inspects refs directly, the bookmarks it needs are not necessarily where it expects to find them. The README notes that all core developers use Jujutsu to develop Jujutsu on GitHub, which shows the path works for that project, but it does not generalise to every forge integration.

The second limitation is maturity. Releases are frequent and versioned in the 0.x range, with v0.45.1, v0.45.0 and v0.44.0 in the recent list. A 0.x version number is not proof of instability on its own, but combined with the README's own warning about backwards incompatible storage changes in experimental features, it means you should not treat the on-disk format as a long-term commitment without checking the release notes for the versions you cross.

The third is the absence of a staging area. For some teams that is the feature. For a team whose review process is built around carefully staged commits produced with git add -p, removing the index moves that selection work to a later rewriting step, and the tooling around review may not line up with the result.

Git is the alternative, and the difference is the data model

The obvious alternative is Git itself, and the README links a dedicated comparison page at docs.jj-vcs.dev/latest/git-comparison. The difference is not speed or syntax. It is what the system considers a first-class object.

In Git, the index is a real object you manipulate, conflicts are textual diffs you resolve in the working tree, and rebasing descendants is a command you run deliberately, with rerere as a separate opt-in cache for reusing resolutions. In Jujutsu, the working copy is a commit that is amended automatically, conflicts are first-class objects tracked by the model, and descendants rebase automatically when an ancestor changes, with resolutions propagating. Git's model puts the user in charge of when history is rewritten. Jujutsu's model rewrites as a side effect of editing.

That is a real trade. The jj model removes a class of bookkeeping, and it also removes the checkpoint where you would normally stop and reconsider. If you want a tool that does exactly what you told it and nothing more, Git's explicitness is a feature, not a gap. Mercurial and Sapling are named in the README as sources of inspiration rather than competitors in the same storage sense, and Darcs is cited for the theory-of-patches contrast. Among these, Git is the one you can adopt with zero migration cost, which is the honest baseline for any comparison.

Maintenance cost, licensing, and what to check before committing

The project is licensed Apache-2.0, per the repository metadata and the licence badge in the README. Apache-2.0 is a permissive licence with an explicit patent grant, which matters for corporate adoption, but nothing here is legal advice and the LICENSE file in the repository is the authoritative text.

Maintenance cost has two parts. The first is upgrade cost. The release cadence visible in the repository is roughly monthly, with v0.44.0 in early August and v0.45.0 and v0.45.1 in early September. For a 0.x project, that pace means release notes are not optional reading if you care about storage compatibility, particularly for the features the README flags as experimental.

The second is the cost of the metadata split. Anything that needs to understand bookmarks has to go through jj rather than through Git, so scripts and CI steps written against Git refs may need rework. That is a one-time cost, but it recurs whenever you add tooling that assumes Git is the whole story.

Before adopting, verify three things against your own environment: that the installation path for your platform is covered on the install-and-setup page, that the forge you use can work with commits stored in Git while bookmarks live outside it, and that the concurrency guarantees described in the technical documentation match how you actually store repositories. The README's warning block is the boundary between what is supported and what is still in motion, and it is short enough to read in full.

Editorial conclusion

Adopt jj if you want patch-based workflows, an undoable operation log, and automatic rebasing of descendants while keeping Git repositories as the storage layer. Do not adopt it if your team depends on Git forges reading branch metadata, since bookmarks and other higher-level metadata live outside Git, or if you cannot tolerate experimental features that the README warns may involve backwards incompatible storage changes. Verify first that your installed version matches the current release line (v0.45.1 at the time of writing) and read the concurrency documentation before pointing any sync or backup tool at a jj repository.

Official sources

1. jj-vcs/jj on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases