Jujutsu

Version control provides the fundamental foundation for collaborative software engineering, but the interface choices made by older systems often surface internal abstractions that developers must manually manage. Jujutsu offers an alternative approach to tracking source history. Built with a strong focus on usability and consistency, Jujutsu reconsiders how version control interacts with the working copy, history rewriting, and conflict resolution workflows.

Jujutsu is designed with an abstract underlying data and storage model, where the Git backend is currently the only production-ready option. This backend design enables users to interact seamlessly with existing Git remote repositories using familiar hosting providers, while leveraging a completely different user interface and conceptual model locally on their workstations.

Rethinking the working copy

Traditional version control workflows often separate the working directory, the staging area, and the committed history into distinct concepts. This separation can lead to friction when switching tasks, saving work in progress, or trying to understand what changes are ready to be published. By not requiring an explicit index or staging area, Jujutsu avoids some of the complexity found in Git.

Instead, a real commit is used to represent the working copy in Jujutsu, and checking out a commit automatically creates a new working-copy commit on top of it. Whenever files are changed in the local working directory, those modifications update the active commit automatically. Because the working copy is simply another standard commit, users can amend its message, rebase it across the history tree, or squash it exactly as they would any historical commit in the project.

Cloning and observing state

To start a new local project from an existing Git repository, Jujutsu provides a clone command that initializes the local environment and sets up the necessary remote tracking branches. The following command creates a local clone of a remote Git repository:

After cloning completes, the repository contains a brand-new working-copy commit ready for edits. To observe the current state of the directory and any active changes, use the status command:

This output displays the current working copy commit, its parent commit, and any file modifications present. Since changes are continuously recorded in the active commit, developers do not need to explicitly add files before reviewing their status, eliminating an entire class of forgotten-file errors.

Tracking operations for safe recovery

Rewriting history and experimenting with repository state can sometimes lead to unexpected outcomes or lost commits. To address this risk, Jujutsu maintains a log of every repository operation, such as commits, pulls, and pushes, enabling simpler undo workflows. If a complex rebase conflicts or a checkout points to the wrong parent branch, the robust operation log allows the user to restore the repository to its exact previous state without relying on obscure reference logs.

Because the system tracks conflicts as first-class objects rather than textual diffs, a conflict does not necessarily block further operations. A user can safely rebase a conflicted commit, and the conflict markers will propagate automatically through the graph, allowing the final resolution to occur at a more convenient point in the workflow.

For more information, refer to the official Jujutsu repository and its official tutorial.