add jujutsu article

Tuprules.tup

@@ -19,7 +19,17 @@ 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
 !thumbnail = |> ^ %f -> thumbnail^ convert %f -resize 200x200 $(JPG_OPT) %o |>
+
+#
+# Slides
+#
+MARP = npx @marp-team/marp-cli@latest
+MARP_OPTS = --allow-local-files --bespoke.progress
+!marp_pdf = |> $(MARP) $(MARP_OPTS) %f --pdf --output %o |> %B.pdf
+!marp_html = |> $(MARP) $(MARP_OPTS) %f --html --output %o |> %B.html

articles/jujutsu/Tupfile

@@ -0,0 +1,9 @@
+include_rules
+HTML_TEMPLATE = article.html
+
+: 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

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

articles/jujutsu/slides.md

@@ -0,0 +1,131 @@
+---
+marp: false
+theme: gaia
+footer: '**Fabien Freling** - 2025-02-17'
+paginate: true
+---
+
+<style>
+section::after {
+  content: attr(data-marpit-pagination) '/' attr(data-marpit-pagination-total);
+}
+</style>
+
+
+<!--
+_class: lead
+-->
+
+# Jujutsu
+
+![](./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)
+

articles/web_stack.md

@@ -1,6 +1,7 @@
 ---
 title: Web stack
 date: 2019-06-26
+update: 2024-11-26
 ---
 
 Previous stacks

flake.nix

@@ -7,10 +7,13 @@
       devShell.x86_64-linux = with pkgs;
         mkShell {
           nativeBuildInputs = [
+            entr
+            graphviz-nox
             imagemagick
             just
             libavif
             libjxl
+            nodejs
             nushell
             pandoc
             tup

justfile

@@ -1,8 +1,8 @@
-# vim: set ft=make :
+root := justfile_directory()
-root := `pwd`
+build := root / "build"
 
 # Build static website
-build:
+build: jj-slides
     tup build
 
 clean:
@@ -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