add jujutsu article

Tuprules.tup

@@ -1,6 +1,5 @@
 &root = .
 &tmpl_dir = ./templates
-&gen_tmpl_dir = ./build/templates
 
 HTML_TEMPLATE = main.html
 
@@ -10,8 +9,8 @@ HTML_TEMPLATE = main.html
 	--template=&(tmpl_dir)/$(HTML_TEMPLATE) \
 	--include-in-header=&(tmpl_dir)/header.html \
 	--include-before-body=&(tmpl_dir)/nav.html \
+	--include-after-body=&(tmpl_dir)/footer.html \
 	--css &(root)/css/style.css \
-	--include-after-body=&(gen_tmpl_dir)/footer.html \
 	%f | sed 's|%%webRoot%%|&(root)|g' > %o \
 	|> %B.html
 
@@ -20,6 +19,8 @@ HTML_TEMPLATE = main.html
 !compress_png = |> zopflipng %f %o |>
 !compress_jpg = |> cjpeg -quality 80 -progressive -outfile %o %f |>
 !compress_pdf = |> ps2pdf %f %o |>
+!avif = |> avifenc %f %o |> %B.avif
+!jxl = |> cjxl %f %o |> %B.jxl
 
 JPG_OPT = -quality 80 -strip -interlace Plane
 !blur_mini = |> ^ %f -> blur mini^ convert %f -resize 400x400 -blur 0x8 $(JPG_OPT) %o |> blur_mini.jpg

articles/jujutsu/Tupfile

@@ -1,6 +1,9 @@
 include_rules
 HTML_TEMPLATE = article.html
 
-: slides.md |> !marp_pdf |> jujutsu_slides.pdf ./<deps>
+: foreach *.png |> !avif |>
+: foreach *.png |> !jxl |>
 : index.md | ./<deps> |> !html |>
 
+# images embedding not working in marp + tup
+# : slides.md |> !marp_pdf |> jujutsu_slides.pdf ./<deps>

articles/jujutsu/index.md

@@ -1,16 +1,24 @@
 ---
 title: "Lightning talk: Jujutsu"
-date: 2024-11-26
+date: 2025-02-17
 ---
 
 _This article is also available as a lightning talk: [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/martinvonz/jj) is a new version control software
-(VCS), like git, mercurial, etc. Git is the actual gold standard for VCS, even if its
+[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 plans on
+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
@@ -31,10 +39,116 @@ 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
+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)

articles/jujutsu/slides.md

@@ -1,7 +1,7 @@
 ---
-marp: true
+marp: false
 theme: gaia
-footer: '**Fabien Freling** - 2024-11-26'
+footer: '**Fabien Freling** - 2025-02-17'
 paginate: true
 ---
 
@@ -18,6 +18,114 @@ _class: lead
 
 # Jujutsu
 
-Life after Git
+![](./jj-logo.png)
 
 ---
+
+## What is it?
+
+* New version control software (VCS)
+* Separation of **frontend** and **backend**
+* Compatible with git
+* Slowly replacing git cli at Google (askip)
+* Aiming for a simpler workflow
+
+---
+
+## No branch, only revisions
+
+![](./jj_02.png)
+<revision id> <author> <date> <branch> <commit id>
+
+- @ working copy
+- ◆ immutable
+- × conflict
+
+---
+
+## Embrace the DETACHED HEAD
+
+- No need to be at the tip of a branch
+- Easy to change the current revision (no rebase step)
+- Each revision has a scope, you can switch / split / squash
+- You can modify other branches, not only the current one (there is none)
+
+---
+
+## Immutable revisions
+
+- New concept
+- By default `master` is immutable, sane choice
+- Clearly express what would create conflict, even local copy cannot change
+- You can override it (but don't)
+
+---
+
+## No staging area, everything is logged
+
+- You need a good gitignore
+- You can always switch commits without loss
+- You might want to recreate a "staging" commit
+
+---
+
+## Conflicts are ok
+
+- Conflicts are recorded but never stop a rebase
+- Conflicted commits are annotated
+- You can safely rebase, deal with conflicts later on
+- No need to mark as resolved
+
+---
+
+## Branches, bookmarks
+
+- Branches (git) = bookmarks (jujutsu)
+- Optional during dev
+- Mandatory when pushing
+- Stick to revision, manual step to update
+- Tracked bookmarks are updated during fetch
+  - No sync conflict between a local copy and its remote
+
+---
+
+## Back to git?
+
+- A way back is always possible
+- git view gets confused in detached HEAD
+
+---
+
+## Tooling
+
+- Battery included
+  - CLI tool for splitting commits
+- Git tools not compatible
+
+---
+
+## Takeaway
+
+- 🤩 Good when dealing with multiple tracks
+- 😔 Need to explicitely specify branch when pushing commits
+- Small improvements, not game-changing
+- 😔 No ecosystem, but it's growing (TUI)
+- Native backend (not ready yet) would remove a lot of friction
+
+---
+
+<!--
+_class: lead
+-->
+
+## Worth the switch?
+
+# ✋ Not yet
+
+---
+
+# References
+
+- [Official website](https://jj-vcs.github.io/jj/)
+  - [GUI & TUI](https://github.com/jj-vcs/jj/wiki/GUI-and-TUI)
+

flake.nix

@@ -7,6 +7,7 @@
       devShell.x86_64-linux = with pkgs;
         mkShell {
           nativeBuildInputs = [
+            entr
             graphviz-nox
             imagemagick
             just

justfile

@@ -1,5 +1,5 @@
-# vim: set ft=make :
-root := `pwd`
+root := justfile_directory()
+build := root / "build"
 
 # Build static website
 build:
@@ -23,3 +23,13 @@ deploy: build
 
 preview: build
     python3 -m webbrowser -t "file://{{root}}/build/index.html"
+
+JJ_SLIDES_SRC := root / "articles/jujutsu/slides.md"
+JJ_SLIDES_OUT := build / "articles/jujutsu/jujutsu_slides.pdf"
+jj-slides:
+    npx @marp-team/marp-cli@latest --allow-local-files \
+    --bespoke.progress {{ JJ_SLIDES_SRC }} --pdf \
+    --output {{ JJ_SLIDES_OUT }}
+
+jj-slides-watch:
+    ls {{ JJ_SLIDES_SRC }} | entr just jj-slides

templates/Tupfile

@@ -1 +0,0 @@
-: |> ./generate_footer.sh > %o |> footer.html ./<tmpl_group>

templates/footer.html

@@ -0,0 +1,3 @@
+<div id="footer">
+Copyright &copy; Fabien Freling since 2007
+</div>

templates/generate_footer.sh

@@ -1,9 +0,0 @@
-#!/usr/bin/env bash
-
-set -euo pipefail
-
-cat << EOF
-<div id="footer">
-Copyright &copy; Fabien Freling 2007-$(date +%Y)
-</div>
-EOF