add jujutsu article

Tuprules.tup

@@ -1,5 +1,6 @@
 &root = .
 &tmpl_dir = ./templates
+&gen_tmpl_dir = ./build/templates
 
 HTML_TEMPLATE = main.html
 
@@ -9,8 +10,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
 
@@ -19,8 +20,6 @@ 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,9 +1,6 @@
 include_rules
 HTML_TEMPLATE = article.html
 
-: foreach *.png |> !avif |>
+: slides.md |> !marp_pdf |> jujutsu_slides.pdf ./<deps>
-: 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,24 +1,16 @@
 ---
 title: "Lightning talk: Jujutsu"
-date: 2025-02-17
+date: 2024-11-26
 ---
 
 _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/jj-vcs/jj) is a new version control software (VCS),
+[Jujutsu](https://github.com/martinvonz/jj) is a new version control software
-like git, mercurial, etc. Git is the actual gold standard for VCS, even if its
+(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
+to similar projects (eg. mercurial) a daunting task. How does jujutsu plans on
 making us switch?
 
 Jujutsu separates the frontend (what the user interacts with) and the
@@ -39,116 +31,10 @@ 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
+There is no special mode like git's "Detached HEAD", you are always on a revision. You can jump around
-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: false
+marp: true
 theme: gaia
-footer: '**Fabien Freling** - 2025-02-17'
+footer: '**Fabien Freling** - 2024-11-26'
 paginate: true
 ---
 
@@ -18,114 +18,6 @@ _class: lead
 
 # Jujutsu
 
-![](./jj-logo.png)
+Life after Git
 
 ---
-
-## 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,7 +7,6 @@
       devShell.x86_64-linux = with pkgs;
         mkShell {
           nativeBuildInputs = [
-            entr
             graphviz-nox
             imagemagick
             just

justfile

@@ -1,5 +1,5 @@
-root := justfile_directory()
+# vim: set ft=make :
-build := root / "build"
+root := `pwd`
 
 # Build static website
 build:
@@ -23,13 +23,3 @@ 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

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

templates/footer.html

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

templates/generate_footer.sh

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