Jujutsu (jj): a Git-compatible VCS with automatic commits and undo

What Jujutsu solves, and who it is for

Git's model asks you to name things before you know whether they matter. You stage part of a change, decide whether it belongs on a branch, and only then commit. Jujutsu removes those decisions from the critical path. The README describes the working copy as a commit that is amended on every file change, which means there is no staging area and no stash to manage. A separate change is a separate commit, and you name it only when you want to share it.

The second problem is history rewriting. In Git, editing an older commit means an interactive rebase and a round of conflict resolution that you repeat for every descendant. Jujutsu rebases descendants automatically and propagates conflict resolutions through them, which the README compares to a transparent combination of git rebase --update-refs and git rerere. If your workflow is a stack of small patches that you reorder and amend all day, that difference is the whole product.

The intended audience is broad on paper: the README says it is designed to be easy to use whether you are new or experienced, working alone or on a large project. In practice the people who get the most out of it are comfortable with Git internals, because Jujutsu does not hide them. It is also explicitly aimed at anyone who wants to keep using Git forges, since Git repositories are the default storage layer.

Working copy as a commit, and the operation log

Jujutsu separates the user interface and the version control algorithms from the storage system. The README states that this abstraction lets it serve as a VCS over several possible physical backends, naming Mercurial, Breezy and Google's Piper/CitC as examples. Today the shipping backend is Git, and the README is explicit about the split: commits and files are stored in Git, while bookmarks (branches) and other higher-level metadata live in custom storage outside Git. That single sentence explains most interoperability surprises. A Git tool can read your commits, but it cannot see your bookmarks.

The model has one visible object type: the commit. Every change to a tracked file is snapshotted into the current commit and amended on the next change. There is no index, so there is nothing to stage. Conflicts are first-class objects in the model rather than textual diff markers, which is what allows a resolution to be recorded and propagated. The README is careful about the lineage here: it credits Darcs with a formalized theory of patches and describes Jujutsu's approach as snapshot-based and less rigorous, with the practical effect that many conflict resolutions can be applied automatically.

Every operation, from commits to pulls to pushes, is written to an operation log. The README frames this as an answer to "what just happened?" and "how did I end up here?", including when you are helping a coworker debug their repository. Because the log is complete, an operation can be undone. This is the feature that most changes how you work: mistakes stop being permanent before you have pushed.

Installing jj and making a first commit

The README points to a dedicated installation page at docs.jj-vcs.dev/latest/install-and-setup rather than listing package commands inline, so the exact package manager invocation depends on your platform and is not reproduced here. The repository does build from source with Cargo: Cargo.toml declares the workspace version as 0.45.1 and a minimum Rust version of 1.97.1, and the workspace members are cli, core, lib and their support crates.

Once the binary is on your PATH, the tutorial path starts by cloning an existing Git repository. Jujutsu reads and writes the same object store, so this is a normal clone from the forge's point of view. The README's homepage is https://www.jj-vcs.dev and the getting-started guide lives at docs.jj-vcs.dev/latest/tutorial.

You land on a commit that represents the working copy. Editing a file and checking the state shows the change already recorded in that commit, with no add or stage step in between. The README does not reproduce the individual subcommands in the section available here, so consult the tutorial page for the exact spellings before scripting anything.

Where Jujutsu gets in your way

The storage split is the sharpest limitation. Because bookmarks and higher-level metadata are not stored in Git, a teammate working in plain Git will not see your bookmark through the usual remote-tracking refs. The README acknowledges the trade-off directly: only commits and files go into Git. Anyone evaluating Jujutsu for a mixed team should test the push and fetch path against their actual forge before assuming it behaves like a Git branch.

The README also carries a warning block. Safe, concurrent replication is listed as available but experimental, with possible bugs, backwards incompatible storage changes and user-interface changes. The scenario it describes is storing repositories in a Dropbox folder or backing them up to S3, and the claim is that concurrent copies should never corrupt the repository, at worst exposing conflicts to resolve. That is a meaningful design goal, but the project itself files it under experimental, so it is not a reason to move production backups onto it.

The third constraint is the ecosystem. Git hooks, submodules, partial clone filters and any tool that assumes an index have no equivalent described in the available documentation. Jujutsu is Git-compatible at the storage layer, not at the interface layer, and the README's own framing supports that reading. If your CI pipeline calls git commands against a checked-out working tree, verify each one rather than assuming compatibility.

Jujutsu against Git and Mercurial-style tools

The obvious alternative is Git itself. The difference is not storage, since Jujutsu uses Git repositories, but the editing model. Git treats the index as the place where you compose a commit; Jujutsu treats the working copy as a commit that is always current. Git's rebase rewrites one commit and leaves you to fix descendants; Jujutsu rebases descendants automatically and carries conflict resolutions forward. Git's reflog records ref movements; Jujutsu's operation log records operations and lets you undo them.

Mercurial and Sapling are the other reference points, and the README is explicit about what Jujutsu borrows: the revset language for selecting commits, anonymous branches so that small changes do not need names, no explicit index or staging area, and a configurable template language for output formatting. If you already like Mercurial's revsets, Jujutsu gives you that vocabulary on top of Git storage, which is a combination neither tool offers on its own.

Darcs is the third comparison, and the README is honest that Jujutsu does not match it. Darcs is built on a formalized theory of patches; Jujutsu is snapshot-based and treats conflicts as first-class objects instead. The practical consequence is that some conflict resolutions propagate automatically, but the model is not as rigorous as a patch-theoretic system. If correctness of patch algebra is your concern, that distinction matters more than the feature list.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-10. Releases are frequent: v0.45.0 and v0.45.1 both landed on 2026-09-03, with v0.44.0 on 2026-08-06. The version numbers are still in the 0.x range, which the project's own release cadence makes meaningful: minor versions arrive roughly monthly, and a 0.x project is free to make backwards incompatible changes. The README's experimental warning on concurrent replication is a concrete example of that policy in action.

Upgrading is not just a binary swap if you use the storage backend. The Cargo.toml pins the workspace Rust version at 1.97.1 and the package version at 0.45.1, and the comment next to rust-version reminds maintainers to update CI, mise.toml, contributing.md, changelog.md and install-and-setup.md together. That is a signal about how many places a version bump touches. For a user, the practical upgrade cost is reading CHANGELOG.md before moving between minor versions, particularly if you rely on the experimental features.

The licence is Apache-2.0, declared both in the repository metadata and in Cargo.toml. Apache-2.0 is a permissive licence with an explicit patent grant, which is generally straightforward for commercial use. Whether it fits your organisation's policy on attribution and NOTICE files is a question for your legal team, not something this review can settle.

Editorial conclusion

Adopt Jujutsu if you rewrite commits constantly, work alone or on a small team, and still need to push to a Git forge. Do not adopt it if your team depends on Git hooks, submodules or a GUI that speaks only Git, and do not treat the concurrent-replication feature as production-ready: the README marks it experimental. Before committing, clone one of your own repositories with Jujutsu and check that your editor, CI and forge integrations still behave.

Frequently asked questions

Official sources

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