diff --git a/Tuprules.tup b/Tuprules.tup index e342576..a1c3ed5 100644 --- a/Tuprules.tup +++ b/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 diff --git a/articles/jujutsu/Tupfile b/articles/jujutsu/Tupfile index a3775a5..df556c8 100644 --- a/articles/jujutsu/Tupfile +++ b/articles/jujutsu/Tupfile @@ -1,9 +1,6 @@ include_rules HTML_TEMPLATE = article.html -: foreach *.png |> !avif |> -: foreach *.png |> !jxl |> +: slides.md |> !marp_pdf |> jujutsu_slides.pdf ./ : index.md | ./ |> !html |> -# images embedding not working in marp + tup -# : slides.md |> !marp_pdf |> jujutsu_slides.pdf ./ diff --git a/articles/jujutsu/index.md b/articles/jujutsu/index.md index 7df006a..1059614 100644 --- a/articles/jujutsu/index.md +++ b/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)_ -

- - - - jujutsu logo - -

- ## 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 +[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 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 -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] - +There is no special mode like git's "Detached HEAD", you are always on a revision. You can jump around ## 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) diff --git a/articles/jujutsu/jj-logo.png b/articles/jujutsu/jj-logo.png deleted file mode 100644 index dc94ced..0000000 Binary files a/articles/jujutsu/jj-logo.png and /dev/null differ diff --git a/articles/jujutsu/jj_01_commits.png b/articles/jujutsu/jj_01_commits.png deleted file mode 100644 index 1d58bcf..0000000 Binary files a/articles/jujutsu/jj_01_commits.png and /dev/null differ diff --git a/articles/jujutsu/jj_01_revs.png b/articles/jujutsu/jj_01_revs.png deleted file mode 100644 index 1969406..0000000 Binary files a/articles/jujutsu/jj_01_revs.png and /dev/null differ diff --git a/articles/jujutsu/jj_02.png b/articles/jujutsu/jj_02.png deleted file mode 100644 index af437d3..0000000 Binary files a/articles/jujutsu/jj_02.png and /dev/null differ diff --git a/articles/jujutsu/slides.md b/articles/jujutsu/slides.md index eb18126..b3ab148 100644 --- a/articles/jujutsu/slides.md +++ b/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) - - -- @ 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 - ---- - - - -## 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) - diff --git a/flake.nix b/flake.nix index 994956d..df507e3 100644 --- a/flake.nix +++ b/flake.nix @@ -7,7 +7,6 @@ devShell.x86_64-linux = with pkgs; mkShell { nativeBuildInputs = [ - entr graphviz-nox imagemagick just diff --git a/justfile b/justfile index 04019d3..36a8e8f 100644 --- a/justfile +++ b/justfile @@ -1,5 +1,5 @@ -root := justfile_directory() -build := root / "build" +# vim: set ft=make : +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 diff --git a/templates/Tupfile b/templates/Tupfile new file mode 100644 index 0000000..f179092 --- /dev/null +++ b/templates/Tupfile @@ -0,0 +1 @@ +: |> ./generate_footer.sh > %o |> footer.html ./ diff --git a/templates/footer.html b/templates/footer.html deleted file mode 100755 index d1d3b81..0000000 --- a/templates/footer.html +++ /dev/null @@ -1,3 +0,0 @@ - diff --git a/templates/generate_footer.sh b/templates/generate_footer.sh new file mode 100755 index 0000000..54df8f5 --- /dev/null +++ b/templates/generate_footer.sh @@ -0,0 +1,9 @@ +#!/usr/bin/env bash + +set -euo pipefail + +cat << EOF + +EOF