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

> A version control system that combines the best ideas from Git, Mercurial, and Pijul with automatic rebasing, first-class conflicts, and a working-copy-as-commit model.

## Install

Save as a script file and run:

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

## Quick Use
```bash
cargo install --locked jj-cli
jj git clone https://github.com/user/repo.git
jj new   # start a new change
jj commit -m "my change"
```

## 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/

---
Source: https://tokrepo.com/en/workflows/asset-e52ce9fe
Author: Script Depot