Bug#1061772: RFP: jujutsu -- Git-compatible VCS that is both simple and powerful
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-rust@lists.debian.org
* Package name : jujutsu
Version : 0.13.0
Upstream Contact: Martin von Zweigbergk <https://github.com/martinvonz>
* URL : https://martinvonz.github.io/jj/
* License : Apache-2.0
Programming Lang: Rust
Description : Git-compatible VCS that is both simple and powerful
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! 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.
* Pijul & 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 and
Pijul (which are 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.
[!WARNING] The 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 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".
----
There's been many attempts at "redoing" Git out there and indeed jj
lists a few in:
https://martinvonz.github.io/jj/v0.13.0/related-work/
... some are even possibly packaged in Debian (e.g. gitless). But none
go so far as jj *while being compatible with git* (except maybe
sapling).
I find the idea of automated working-tree commits to be quite
intruiguing and i love the backwards compatibility with git. So I
wonder when we should packge this in Debian. :)
Reply to: