Jujutsu (jj) — A Git-Compatible Next-Generation Version Control System

Introduction

Jujutsu (jj) rethinks version control by treating the working copy as a commit, making conflicts first-class objects, and providing automatic rebasing. It uses Git as its storage backend, so it works seamlessly with existing Git repositories and hosting platforms.

What Jujutsu Does

• Operates on Git repositories without requiring migration or conversion
• Treats the working directory as a mutable commit that is continuously snapshotted
• Records conflicts as structured data that can be rebased, merged, and resolved incrementally
• Automatically rebases dependent changes when ancestors are amended
• Supports anonymous branches and a revision-set query language for navigating history

Architecture Overview

Jujutsu separates the commit graph logic from the storage backend. The default backend is Git, meaning all data is stored in a standard .git directory. The operation log records every state mutation, enabling undo at any point. The working copy is tracked as a special commit whose diff is computed on every command invocation, eliminating the index/staging area complexity of Git.

Self-Hosting & Configuration

• Install via cargo install jj-cli, Homebrew, or Nix packages
• Works with any existing Git repository by running jj git init --colocate in a clone
• Configure in ~/.jjconfig.toml for user identity, editor, merge tool, and aliases
• Push and fetch from any Git remote (GitHub, GitLab, etc.) using jj git push/fetch
• Co-locate mode keeps .git intact so Git and jj commands can be used side by side

Key Features

• Working-copy-as-commit model eliminates the need for stash, staging area, or detached HEAD
• Operation log allows undoing any command, including rebases and merges
• Conflict handling allows you to rebase conflicting changes without resolving immediately
• Revsets query language (`jj log -r 'ancestors(x) & author(name)') for flexible history exploration
• Supports both a change-based (anonymous branch) and branch-based workflow

Comparison with Similar Tools

• Git — requires explicit staging and stashing; jj auto-snapshots and auto-rebases
• Mercurial — similar revision concepts; jj adds first-class conflicts and uses Git storage
• Pijul — patch-theory-based VCS; jj is more pragmatic with Git interoperability
• Sapling (Meta) — smartlog-based UX; jj has richer conflict handling and operation undo
• GitButler — GUI-focused branching; jj is CLI-first with deeper VCS model changes

FAQ

Q: Can I use jj with GitHub pull requests? A: Yes. Push named branches with jj git push and create PRs normally on GitHub.

Q: Does jj replace Git entirely? A: It uses Git for storage and network, so collaborators can still use Git without knowing you use jj.

Q: How does undo work? A: jj undo reverts the last operation. jj op log shows all operations, and you can restore any prior state.

Q: Is jj production-ready? A: It is used daily at Google and by a growing community. The core model is stable but the CLI surface is still evolving.

Sources

• https://github.com/martinvonz/jj
• https://martinvonz.github.io/jj/latest/