JujutsuExperimental

A Git-compatible version control system, run as jj, where the working copy is itself a commit, every operation can be undone, and conflicts are stored in commits instead of stopping you.

What it is: Version control
Type: Open source
Made by: The Jujutsu project
License: Apache 2.0
Status: Experimental. Still before 1.0: its README calls it an experimental version control system and warns of backward-incompatible changes to workflows and on-disk formats before 1.0.0. Git compatibility is stable.
Facts checked: 20 October 2026

What it is

Jujutsu keeps its version control model separate from storage, and today the production-ready backend is an ordinary Git repository. Commits and files are stored as Git objects (through the gitoxide Rust library, with the git command used for fetch and push), so you can use it on any Git repository and push to any Git forge, and teammates just see Git commits. Bookmarks, its name for branches, and its other metadata live in its own .jj directory. Since 0.34 (October 2025) jj git init and jj git clone create colocated workspaces with both .jj and .git, so jj and git commands work in the same directory.

Three ideas set it apart. The working copy is a real commit, called @: almost every command first snapshots your files into it, so there is no staging area, no git stash, and no command fails because the tree is dirty; jj new starts the next change on top. Every operation, from a commit to a fetch, is recorded in an operation log with a snapshot of the repo, so jj undo reverses the last one and jj op restore returns the repo to any earlier state. And a conflict is stored in the commit as data, not as markers, so a rebase or merge always completes; when you edit a commit, its descendants are rebased automatically, and a conflict resolution flows down to them too. Each change also has a stable change ID, 12 letters from k to z in jj log, that survives rewrites while its Git commit ID changes.

Martin von Zweigbergk started Jujutsu as a hobby project in late 2019; it is now his full-time project at Google, with other Googlers helping, but the README says it is not a supported Google product. It is written in Rust, licensed under Apache 2.0 and run by elected maintainers. A new 0.x release comes out about once a month; the latest is 0.46.0 (October 7, 2026), which lets extra workspaces be colocated as Git worktrees.

Why teams pick it

Adopt it alone: it works on an existing Git repository and with any Git forge, and you can switch back to Git at any time
Mistakes are cheap: the operation log lets you undo or redo any operation, including rebases and fetches
Rewriting history is a first-class workflow: jj describe, jj split and jj squash --into work on any commit, and descendants follow automatically
Conflicts never interrupt a command, so there is no --continue state, and a resolution propagates to every descendant

Watch out for

Pre-1.0: commands and on-disk formats can still change in backward-incompatible ways, and it ships a new 0.x release roughly monthly
Git features it doesn’t support: submodules, partial clones, .gitattributes, Git hooks and Git LFS
It can only create lightweight tags, not annotated ones, and has no native email-patch workflow
New concepts to learn: change IDs beside commit IDs, revsets, and auto-tracking that snapshots every new file unless it is ignored

Alternatives

What all version control have in common →Compare side by side →

GitOpen sourceThe distributed version control system almost everyone uses: every clone holds the full history, stored as objects named by the hash of their content.+1 Git LFS

MercurialOpen sourceA distributed version control system from the same month as Git, written mostly in Python, with a smaller command set, append-only storage and “phases” that stop you rewriting history others already have.

SaplingOpen sourceMeta’s source control system, grown out of Mercurial: an open-source sl client that works with Git repositories and makes stacks of commits and undo easy, plus a server and virtual filesystem that scale it to Meta’s monorepo.

FossilOpen sourceA distributed version control system from the author of SQLite that keeps a whole project (code, tickets, wiki, forum and chat) in one SQLite database file, served by one small executable with its own web interface.PijulBetaOpen sourceA distributed version control system that stores changes instead of snapshots, built on a mathematical theory of patches: independent changes apply in any order with the same result, and a conflict, once resolved, stays resolved.

How it fits with other technologies

What Jujutsu uses

A first session in a Git repository · bash

jj git clone https://github.com/octocat/Hello-World
cd Hello-World
jj st                          # the working copy is commit @; there is no staging area
jj describe -m 'Fix greeting'  # describe the change before, during or after editing
jj new                         # start the next change on top
jj log                         # change IDs (k-z letters) beside Git commit IDs

jj op log                      # every operation, each with a snapshot of the repo
jj undo                        # reverse the last operation

jj git push --change @-        # push @- under a generated bookmark name

Git habits, translated#

From Jujutsu’s own Git command table. Where Git stops for you, jj usually just records the result.

To do this	Git	Jujutsu
Put the current work aside	`git stash`	`jj new @-` (the old working copy stays as a sibling commit)
Fold the working copy into the previous commit	`git commit --amend -a`	`jj squash`
Reword any older commit	`git commit --fixup=reword:X` then `git rebase --autosquash X^`	`jj describe X`
Split an older commit in two	Not supported (emulated with `edit` in `git rebase -i`)	`jj split -r X`
Finish after a conflict	Fix the file, `git add`, then `git rebase --continue`	Fix the file, then `jj squash`; nothing was interrupted
Undo the last operation	Not supported	`jj undo`, and `jj redo`

See it in a real stack

No architecture uses Jujutsu yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2019–2026

Martin von Zweigbergk started Jujutsu as a hobby project in late 2019 and has used it almost exclusively to develop itself since early January 2021. The public repository began on December 12, 2020, with code imported from his own Mercurial repository. It took ideas from several systems: speed and the Git storage format from Git; revsets, anonymous branches and the absence of an index from Mercurial and Sapling; and conflicts as first-class objects from Darcs.

It became his full-time project at Google. At Git Merge 2022 he presented Google’s plans for it, and LWN reported in January 2024 that he planned a backend for Google’s internal cloud-based storage, which would fetch data lazily, as large monorepos need. The README names Google’s Piper and CitC as an example of the kind of backend the abstract storage layer allows.

Outside Google, LWN covered it in January 2024, and Chris Krycho and Steve Klabnik published introductions in February. The project moved to its own jj-vcs GitHub organization in December 2024, renamed branches to bookmarks in October 2024 because they behaved like Mercurial’s bookmarks rather than Git’s branches, and made colocated Git repositories the default in October 2025.

Why it’s built this way

Abstract storage, with Git as the default backend: Separating the user interface and algorithms from storage lets one tool serve many backends, including Google’s internal one. Storing commits in Git meant people could start using it on today’s repositories and forges with nobody else switching.
Make the working copy a commit: With the working copy as an ordinary commit, commits are the only object users see, internal algorithms get simpler, and stashes and the staging area become unnecessary.
Record every operation in a log: The docs say the operation log exists to allow lock-free concurrency: concurrent jj commands, even on different machines over a distributed file system, can’t corrupt the repo, and divergent results show up as conflicts. Undo comes almost for free.
Store conflicts in commits: Recording a conflict as data instead of failing means rebases and merges always finish, descendants can be rebased automatically, and merge commits can be rebased correctly, which neither Git nor Mercurial does.

Timeline

2019
Martin von Zweigbergk starts Jujutsu as a hobby project (late 2019)
2020
Public repository begins December 12, imported from his Mercurial repository
2023
His Git Merge 2022 talk on Google’s plans for Jujutsu is published (January)
2024
Branches renamed bookmarks in 0.22 (October); the repository moves to the jj-vcs organization (December)
2025
0.33 adds jj redo (September); 0.34 colocates Git repositories by default (October)
2026
0.46.0 released October 7

Sources13 · facts checked 20 October 2026

Improve this page on GitHub