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)
|