jj

Jujutsu—a version control system Homepage   •   Installation   •   Getting Started   •   Development Roadmap   •   Contributing Introduction Jujutsu is a powerful version control system for software projects. You use it to get a copy of your code, track changes to the code, and finally publish those changes for others to see and use. It is designed from the ground up to be easy to use—whether you're new or experienced, working on brand new projects alone, or large scale software projects with large histories and teams. Jujutsu is unlike most other systems, because internally it abstracts the user interface and version control algorithms from the storage systems used to serve your content. This allows it to serve as a VCS with many possible physical backends, that may have their own data or networking models—like Mercurial or Breezy, or hybrid systems like Google's cloud-based design, Piper/CitC. Today, we use Git repositories as a storage layer to serve and track content, making it compatible with many of your favorite Git-based tools, right now! However, note that only commits and files are stored in Git; bookmarks (branches) and other higher-level metadata are stored in custom storage outside of Git. All core developers use Jujutsu to develop Jujutsu, right here on GitHub. But it should hopefully work with your favorite Git forges, too. We combine many distinct design choices and concepts from other version control systems into a single tool. Some of those sources of inspiration include: Git: We make an effort to be fast—with a snappy UX, efficient algorithms, correct data structures, and good-old-fashioned attention to detail. The default storage backend uses Git repositories for "physical storage", for wide interoperability and ease of onboarding. Mercurial & Sapling: There are many Mercurial-inspired features, such as the revset language to select commits. There is no explicit index or staging area. Branches are "anonymous" like Mercurial, so you don't need to make up a name for each small change. Primitives for rewriting history are powerful and simple. Formatting output is done with a robust template language that can be configured by the user. Darcs: Jujutsu keeps track of conflicts as first-class objects in its model; they are first-class in the same way commits are, while alternatives like Git simply think of conflicts as textual diffs. While not as rigorous as systems like Darcs (which is based on a formalized theory of patches, as opposed to snapshots), the effect is that many forms of conflict resolution can be performed and propagated automatically. And it adds several innovative, useful features of its own: Working-copy-as-a-commit: Changes to files are recorded automatically as normal commits, and amended on every subsequent change. This "snapshot" design simplifies the user-facing data model (commits are the only visible object), simplifies internal algorithms, and completely subsumes features like Git's stashes or the index/staging-area. Operation log & undo: Jujutsu records every operation that is performed on the repository, from commits, to pulls, to pushes. This makes debugging problems like "what just happened?" or "how did I end up here?" easier, especially when you're helping your coworker answer those questions about their repository! And because everything is recorded, you can undo that mistake you just made with ease. Version control has finally entered the 1960s! Automatic rebase and conflict resolution: When you modify a commit, every descendent is automatically rebased on top of the freshly-modified one. This makes "patch-based" workflows a breeze. If you resolve a conflict in a commit, the resolution of that conflict is also propagated through descendants as well. In effect, this is a completely transparent version of git rebase --update-refs combined with git rerere, supported by design. WarningThe following features are available for use, but experimental; they may have bugs, backwards incompatible storage changes, and user-interface changes! Safe, concurrent replication: Have you ever wanted to store your version controlled repositories inside a Dropbox folder? Or continuously backup repositories to S3? No? Well, now you can! The fundamental problem with using filesystems like Dropbox and backup tools like rsync on your typical Git/Mercurial repositories is that they rely on local filesystem operations being atomic, serialized, and non-concurrent with respect to other reads and writes—which is not true when operating on distributed file systems, or when operations like concurrent file copies (for backup) happen while lock files are being held. Jujutsu is instead designed to be safe under concurrent scenarios; simply using rsync or Dropbox and then using that resulting repository should never result in a repository in a corrupt state. The worst that should happen is that it will expose conflicts between the local and remote state, leaving you to resolve them. 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". Jujutsu is relatively young, with lots of work to still be done. If you have any questions, or want to talk about future plans, please join us on Discord , start a GitHub Discussion, or send an IRC message to #jujutsu on Libera Chat. The developers monitor all of these channels1. News and Updates 📣 December 2024: The jj Repository has moved to the jj-vcs GitHub organization. November 2024: Version 0.24 is released which adds jj file annotate, which is equivalent to git blame or hg annotate. September 2024: Martin gave a presentation about Jujutsu at Git Merge 2024. Feb 2024: Version 0.14 is released, which deprecates "jj checkout" and "jj merge", as well as jj init --git, which is now just called jj git init. Oct 2023: Version 0.10.0 is released! Now includes a bundled merge and diff editor for all platform