155 lines
6.4 KiB
Markdown
155 lines
6.4 KiB
Markdown
---
|
||
title: "Lightning talk: Jujutsu"
|
||
date: 2025-02-17
|
||
---
|
||
|
||
_Slides available: [pdf](./jujutsu_slides.pdf)_
|
||
|
||
<p style="text-align:center;">
|
||
<picture>
|
||
<source type="image/avif" srcset="jj-logo.avif" />
|
||
<source type="image/jxl" srcset="jj-logo.jxl" />
|
||
<img src="jj-logo.png" alt="jujutsu logo" width=20% />
|
||
</picture>
|
||
</p>
|
||
|
||
## What is it?
|
||
|
||
[Jujutsu](https://github.com/jj-vcs/jj) is a new version control software (VCS),
|
||
like git, mercurial, etc. Git is the actual gold standard for VCS, even if its
|
||
UX could be better. There is a whole ecosystem around git that makes switching
|
||
to similar projects (eg. mercurial) a daunting task. How does jujutsu plan on
|
||
making us switch?
|
||
|
||
Jujutsu separates the frontend (what the user interacts with) and the
|
||
backend (how the information is stored). And the main backend is actually git
|
||
repositories. There is a native backend being developed but it's not ready for
|
||
prime time. Sharing the same backend as the most popular VCS, Jujutsu aims to
|
||
improve on the frontend.
|
||
|
||
## How does it compare?
|
||
|
||
### No branch, only revisions
|
||
|
||
Jujutsu understand git commits, but operates at a higher level with revisions.
|
||
Revisions wrap commits, however as you move revisions around (edit with changes,
|
||
or rebase), they keep their id. Only their underlying commit id changes.
|
||
|
||
With revision ids being stable, you don't need branches to start working: create
|
||
a new revision, and start working. You will need to create a branch (or bookmark
|
||
in jujutsu world) to push your changes, but it can be done at the end.
|
||
|
||
There is no special mode like git's "Detached HEAD", you are always on a
|
||
revision. You can jump around the history and you will always see the whole
|
||
history, unlike git where you only see parents revisions.
|
||
|
||
This emphasis on revisions changes the paradigm a bit: you tend to better split
|
||
your revisions, whereas in git you often do smaller commits then clean the whole
|
||
branch during a rebase phase.
|
||
|
||
You can also modify revisions freely: unlike git where you can only modify
|
||
the current branch, you can squash part of any revision into another unrelated
|
||
revision.
|
||
|
||
Some revisions (such as the `main` or `master` branch) are considered immutable,
|
||
meaning you are not allowed to modify them. You can override this but this is a
|
||
sane choice by default.
|
||
|
||
### No staging area
|
||
|
||
Every modification in jujutsu is stored. It removes a step from git and
|
||
avoids scenarios where you cannot switch branches because of a untracked file
|
||
collision, or when you forget to add a file (it works locally but not on the
|
||
CI env).
|
||
|
||
It does require a good .gitignore file to avoid adding unnecessary (big) files,
|
||
but that is good practice anyway.
|
||
|
||
You can mimic git staging area with a new revision on top of your work.[^1]
|
||
|
||
### Conflicts are ok
|
||
|
||
Conflicts during rebase are recorded but never stop the rebase. Revisions will
|
||
be flagged as "conflicted" until the conflict markers are removed. You can then
|
||
see how long the conflicts last (maybe a later revision fixes them).
|
||
|
||
You deal with conflicts how you want, it is never a hurry. You can save your
|
||
progress and change branch in the meanwhile. Once you fix a conflict you do
|
||
not need to explicitely mark them as resolved, the absence of markers is enough
|
||
for jujutsu.
|
||
|
||
### Branch, bookmark
|
||
|
||
A "branch" in git is named "bookmark" in jujutsu. You do not need one during
|
||
dev, you can safely switch revisions trees without naming them. This is very
|
||
useful when you need to try something on top of the main branch: you just
|
||
create a new revision on top of it without creating an dedicated branch or even
|
||
modifying the main branch (I often modified my local copy of the main branch
|
||
this way with git).
|
||
|
||
However, you need a bookmark when you want to push changes to a remote (which is often).
|
||
I believe this could be skipped with a dedicated jujutsu backend.
|
||
|
||
When creating a bookmark, it sticks to the revision it was created on, you need
|
||
to manually update it if you add revision on top of it. This manual step is
|
||
useful when you want to push your changes but keep a few revisions private until
|
||
your work is done.
|
||
|
||
Tracked bookmarks are similar to tracked branches in git, but they are
|
||
automatically updated during fetching. No more out-of-date information between a
|
||
local bookmark and its remote (I'm looking at you `origin/main`).
|
||
|
||
### Tooling
|
||
|
||
Jujutsu comes with nice CLI tools out-of-the-box: you can select part of a commit
|
||
for squashing / splitting with a dedicated TUI, and the log are pretty-printed
|
||
in graph format.
|
||
|
||
But it cannot compare to the exhaustive ecosystem that exists for git: GUI,
|
||
scripts, etc. Unfortunately, git tools are confused when you use jujutsu in
|
||
your repository: they only see the detached HEAD, they are missing the overall
|
||
picture.
|
||
|
||
You can always come back to a regular git workflow based on branches (they are
|
||
mapped on bookmarks), should you need it.
|
||
|
||
### Takeaway
|
||
|
||
Jujutsu shines when you are dealing with multiple tracks (bug hunting,
|
||
work-in-progress, small tests).
|
||
|
||
The need to specify bookmarks when pushing changes feels a bit heavy compared
|
||
to how smooth it is working locally. A backend tailored for jujutsu, supporting
|
||
revisions without bookmarks, would remove a lot of friction.
|
||
|
||
Jujutsu has cool features, but I wouldn't consider them game-changing. It feels
|
||
simpler though, which is good coming from git.
|
||
|
||
The ecosystem is almost null, but it is growing.[^2]
|
||
|
||
|
||
## VCS landscape
|
||
|
||
Jujutsu seems to materialize what the next VCS after git should be: better
|
||
conflict support and nicer UX.
|
||
|
||
It is developed by Googlers and I believe the goal is to slowly replace git CLI
|
||
at Google. It is making good progress with frequent releases.
|
||
|
||
[Sapling](https://sapling-scm.com/) is another contender, developed at Facebook.
|
||
It is more inspired by Mercurial (which is used at Facebook). Its feature set is
|
||
similar to Jujutsu but it seems less popular.
|
||
|
||
> I was part of the team at Meta that built Sapling for many years. I’m no
|
||
> longer at Meta and I use jj full time.
|
||
>
|
||
> _[Discussion on Lobste.rs](https://lobste.rs/s/rojoz1/jujutsu_jj_git_compatible_vcs#c_foqya4)_
|
||
|
||
[Pijul](https://pijul.org/) is less focusing on git compatibility and looks
|
||
more like a research project, focusing on theory of patches. I am not sure how
|
||
production ready it currently is, but the clean break with git means it needs to
|
||
be rock solid to tempt people over.
|
||
|
||
[^1]: [The Squash Workflow](https://steveklabnik.github.io/jujutsu-tutorial/real-world-workflows/the-squash-workflow.html)
|
||
[^2]: [GUI and TUI](https://github.com/jj-vcs/jj/wiki/GUI-and-TUI)
|