add jujutsu article
This commit is contained in:
Fabien Freling
parent
c47942b451
commit
271083d71f
12 changed files with 321 additions and 3 deletions
154
articles/jujutsu/index.md
Normal file
154
articles/jujutsu/index.md
Normal file
|
|
@ -0,0 +1,154 @@
|
|||
---
|
||||
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)
|
||||
Loading…
Add table
Add a link
Reference in a new issue