Jujutsu (jj)

Jujutsu (jj) is a version control system designed to replace git for everyday workflows while keeping git as a backend. Its core design choices are the inverse of git's where they matter:

• Mutable change-IDs. Each change has a stable identity that persists across rebases and amends — what git lacks when it loses the "C2'" relationship to "C2". Successor commits become first-class.
• Operation history. The local op log records every state change to the repo (commit, rebase, undo), so undo, redo, and "what did I do an hour ago" are mechanical.
• Working copy as a commit. The working tree is itself a commit, automatically updated; staging area is gone. Diff-of-diff workflows that don't fit git's model fall out for free.
• Conflicts as data. Unresolved merge conflicts are stored in commits, not in a special filesystem state — you can rebase a conflict forward, resolve it later.
• Git-compatible backend. Repos can be shared with git users; jj reads and writes the same .git/ data.

Why this matters

The piece that motivated this page is billjings-git-not-fine — Bill Jings's argument that git's workflow primitives break down under stacked PRs, async development, and the kind of multi-PR work that becomes common with AI agents. Stacked PRs in particular are a structural mismatch for git but a one-line workflow in jj.

The related framing is in i-dont-want-your-prs and agent-principal-agent-problem — both observing the same workflow shift jj was designed for, even if neither names jj explicitly.

Status

Active project under the jj-vcs organization (github.com/jj-vcs/jj). Google's internal-Piper-flavored ergonomics ported to a public Rust implementation. Several large open-source projects have adopted it for daily work; the git-compatible backend means the rest of a team doesn't have to migrate.

Worth adding to watchlist if a toolbox page is wanted; right now it's a concept page because the wiki references the idea more often than it would reference a specific toolbox entry.