[](https://github.com/jj-vcs/jj/blob/main/LICENSE) [](https://discord.gg/dkmfj3aGQN) [](https://web.libera.chat/?channel=#jujutsu) **[Homepage] • ** **[Installation] • ** **[Getting Started] • ** **[Development Roadmap] • ** **[Contributing](#contributing)** [Homepage]: https://jj-vcs.github.io/jj [Installation]: https://jj-vcs.github.io/jj/latest/install-and-setup [Getting Started]: https://jj-vcs.github.io/jj/latest/tutorial [Development Roadmap]: https://jj-vcs.github.io/jj/latest/roadmap
You can even have a ["co-located" local
repository](https://jj-vcs.github.io/jj/latest/git-compatibility#co-located-jujutsugit-repos)
where you can use both `jj` and `git` commands interchangeably.
### The working copy is automatically committed
Jujutsu uses a real commit to represent the working copy. Checking out a commit
results a new working-copy commit on top of the target commit. Almost all
commands automatically amend the working-copy commit.
The working-copy being a commit means that commands never fail because the
working copy is dirty (no "error: Your local changes to the following
files..."), and there is no need for `git stash`. Also, because the working copy
is a commit, commands work the same way on the working-copy commit as on any
other commit, so you can set the commit message before you're done with the
changes.
### The repo is the source of truth
With Jujutsu, the working copy plays a smaller role than with Git. Commands
snapshot the working copy before they start, then they update the repo, and then
the working copy is updated (if the working-copy commit was modified). Almost
all commands (even checkout!) operate on the commits in the repo, leaving the
common functionality of snapshotting and updating of the working copy to
centralized code. For example, `jj restore` (similar to `git restore`) can
restore from any commit and into any commit, and `jj describe` can set the
commit message of any commit (defaults to the working-copy commit).
### 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](https://jj-vcs.github.io/jj/latest/glossary#conflict),
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).
Basic conflict resolution:
Juggling conflicts:
### 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. Bookmarks pointing to rebased commits will be
updated. So will the working copy if it points to a rebased commit.
### Comprehensive support for rewriting history
Besides the usual rebase command, there's `jj describe` for editing the
description (commit message) of an arbitrary commit. There's also `jj diffedit`,
which lets you edit the changes in a commit without checking it out. To split
a commit into two, use `jj split`. You can even move part of the changes in a
commit to any other commit using `jj squash -i --from X --into Y`.
## Status
The tool is fairly feature-complete, but some important features like support
for Git submodules are not yet completed. There
are also several performance bugs. It's likely that workflows and setups
different from what the core developers use are not well supported, e.g. there
is no native support for email-based workflows.
Today, all core developers use `jj` to work on `jj`. I (Martin von Zweigbergk)
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, we'll try to implement transparent
upgrades (as we've done with recent changes), or provide upgrade commands or
scripts if requested.
## Related work
There are several tools trying to solve similar problems as Jujutsu. See
[related work](https://jj-vcs.github.io/jj/latest/related-work) for details.
## Contributing
We welcome outside contributions, and there's plenty of things to do, so
don't be shy. Please ask if you want a pointer on something you can help with,
and hopefully we can all figure something out.
We do have [a few policies and
suggestions](https://jj-vcs.github.io/jj/prerelease/contributing/)
for contributors. The broad TL;DR:
- Bug reports are very welcome!
- Every commit that lands in the `main` branch is code reviewed.
- Please behave yourself, and obey the Community Guidelines.
- There **is** a mandatory CLA you must agree to. Importantly, it **does not**
transfer copyright ownership to Google or anyone else; it simply gives us the
right to safely redistribute and use your changes.
### Mandatory Google Disclaimer
I (Martin von Zweigbergk,