diff --git a/Tuprules.tup b/Tuprules.tup index b2dce08..e342576 100644 --- a/Tuprules.tup +++ b/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 diff --git a/articles/jujutsu/Tupfile b/articles/jujutsu/Tupfile new file mode 100644 index 0000000..a3775a5 --- /dev/null +++ b/articles/jujutsu/Tupfile @@ -0,0 +1,9 @@ +include_rules +HTML_TEMPLATE = article.html + +: foreach *.png |> !avif |> +: foreach *.png |> !jxl |> +: 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 new file mode 100644 index 0000000..0b1863d --- /dev/null +++ b/articles/jujutsu/index.md @@ -0,0 +1,154 @@ +--- +title: "Lightning talk: Jujutsu" +date: 2025-02-17 +--- + +_Slides available: [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 +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) diff --git a/articles/jujutsu/jj-logo.png b/articles/jujutsu/jj-logo.png new file mode 100644 index 0000000..dc94ced Binary files /dev/null and b/articles/jujutsu/jj-logo.png differ diff --git a/articles/jujutsu/jj_01_commits.png b/articles/jujutsu/jj_01_commits.png new file mode 100644 index 0000000..1d58bcf Binary files /dev/null and b/articles/jujutsu/jj_01_commits.png differ diff --git a/articles/jujutsu/jj_01_revs.png b/articles/jujutsu/jj_01_revs.png new file mode 100644 index 0000000..1969406 Binary files /dev/null and b/articles/jujutsu/jj_01_revs.png differ diff --git a/articles/jujutsu/jj_02.png b/articles/jujutsu/jj_02.png new file mode 100644 index 0000000..af437d3 Binary files /dev/null and b/articles/jujutsu/jj_02.png differ diff --git a/articles/jujutsu/jj_revision.drawio.png b/articles/jujutsu/jj_revision.drawio.png new file mode 100644 index 0000000..66d7151 Binary files /dev/null and b/articles/jujutsu/jj_revision.drawio.png differ diff --git a/articles/jujutsu/slides.md b/articles/jujutsu/slides.md new file mode 100644 index 0000000..eb18126 --- /dev/null +++ b/articles/jujutsu/slides.md @@ -0,0 +1,131 @@ +--- +marp: false +theme: gaia +footer: '**Fabien Freling** - 2025-02-17' +paginate: true +--- + + + + + + +# 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) + + +- @ 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/articles/web_stack.md b/articles/web_stack.md index 1ffc6d8..bface29 100644 --- a/articles/web_stack.md +++ b/articles/web_stack.md @@ -1,6 +1,7 @@ --- title: Web stack date: 2019-06-26 +update: 2024-11-26 --- Previous stacks diff --git a/flake.nix b/flake.nix index e0c7923..994956d 100644 --- a/flake.nix +++ b/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 diff --git a/justfile b/justfile index 36a8e8f..cc8bcc2 100644 --- a/justfile +++ b/justfile @@ -1,8 +1,8 @@ -# vim: set ft=make : -root := `pwd` +root := justfile_directory() +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