ok/jj
1
0
Fork 0
forked from mirrors/jj
A Git-compatible VCS that is both simple and powerful
Find a file
2021-11-07 15:17:51 -08:00
.github github: set RUST_BACKTRACE when running tests 2021-06-13 22:20:09 -07:00
demos demos: add more jj log calls to the working-copy demo 2021-10-27 21:16:29 -07:00
docs docs: mention Breezy as a similar tool 2021-11-04 08:32:42 -07:00
lib working_copy: extract a function for updating the file state and tree if dirty 2021-11-07 15:17:51 -08:00
src cli: use same template for jj log --no-graph as for jj log 2021-10-27 21:28:04 -07:00
tests repo: make .jj/store a directory also in Git-backed repos 2021-10-13 23:42:25 -07:00
.gitignore
Cargo.lock rewrite: add support for rebasing descendants of multiple rewritten commits 2021-09-15 22:13:40 -07:00
Cargo.toml rewrite: add support for rebasing descendants of multiple rewritten commits 2021-09-15 22:13:40 -07:00
LICENSE
README.md docs: explain what the tool is about, not why I started it 2021-10-28 15:01:19 -07:00
rustfmt.toml rustfmt: format string literals 2021-09-02 11:01:02 -07:00

Jujutsu

Disclaimer

This is not a Google product. It is an experimental version-control system (VCS). It was written by me, Martin von Zweigbergk (martinvonz@google.com). It is my personal hobby project. It does not indicate any commitment or direction from Google.

Introduction

Jujutsu is a Git-compatible DVCS. It combines features from Git (data model, speed), Mercurial (anonymous branching, simple CLI free from "the index", revsets), and Pijul/Darcs (first-class conflicts), with features not found in either of them (working-copy-as-a-commit, undo functionality, automatic rebase).

The command-line tool is called jj for now because it's easy to type and easy to replace (rare in English). The project is called "Jujutsu" because it matches "jj".

Features:

  • Compatible with Git

    Jujutsu has two backends. One of them is a Git backend (the other is a native one). This lets you use Jujutsu as an alternative interface to Git. The commits you create will look like regular Git commits. You can always switch back to Git.

  • The working copy is automatically committed

    Most Jujutsu commands automatically commit the working copy. This leads to a simpler and more powerful interface, since all commands work the same way on the working copy or any other commit. It also means that you can always check out a different commit without first explicitly committing the working copy changes (you can even check out a different commit while resolving merge conflicts).

  • Operations update the repo first, then possibly the working copy

    The working copy is only updated at the end of an operation, after all other changes have already been recorded. This means that you can run any command (such as jj rebase) even if the working copy is dirty.

  • Entire repo is under version control

    All operations you perform in the repo are recorded, along with a snapshot of the repo state after the operation. This means that you can easily revert to an earlier repo state, or to simply undo a particular operation (which does not necessarily have to be the most recent operation).

  • Conflicts can be recorded in commits

    If an operation results in conflicts, information about those conflicts will be recorded in the commit(s). The operation will succeed. You can then resolve the conflicts later. One consequence of this design is that there's no need to continue interrupted operations. Instead, you get a single workflow for resolving conflicts, regardless of which command caused them. This design also lets Jujutsu rebase merge commits correctly (unlike both Git and Mercurial).

  • Automatic rebase

    Whenever you modify a commit, any descendants of the old commit will be rebased onto the new commit. Thanks to the conflict design described above, that can be done even if there are conflicts. Branches pointing to rebased commits will be updated. So will the working copy if it points to a rebased commit.

Status

The tool is quite feature-complete, but some important features like (the equivalent of) git blame and git log <paths> are not yet supported. There are also several performance bugs. It's also likely that workflows and setups different from what I personally use are not well supported. For example, pull-request workflows currently require too many manual steps.

I have almost exclusively used jj to develop the project itself since early January 2021. I haven't had to re-clone from source (I don't think I've even had to restore from backup).

There will be changes to workflows and backward-incompatible changes to the on-disk formats before version 1.0.0. Even the binary's name may change (i.e. away from jj). For any format changes, I'll try to implement transparent upgrades (as I've done with recent changes), or provide upgrade commands or scripts if requested.

Installation

# We need the "nightly" Rust toolchain. This command installs that without
# changing your default.
$ rustup install nightly
$ cargo +nightly install --git https://github.com/martinvonz/jj.git

To set up command-line completion, source the output of jj debug completion --bash/--zsh/--fish. For example, if you use Bash:

$ source <(jj debug completion)  # --bash is the default

You may also want to configure your name and email so commits are made in your name. Create a ~/.jjconfig file and make it look something like this:

$ cat ~/.jjconfig
[user]
name = "Martin von Zweigbergk"
email = "martinvonz@google.com"

Getting started

The best way to get started is probably to go through the tutorial.

There are several tools trying to solve similar problems as Jujutsu. See related work for details.