Jujutsu vs Git : le bouton d'annulation que Git n'a jamais eu

Le reflog de Git sauvera vos commits. Il ne vous sauvera pas de la commande que vous avez lancée dessus. Cet écart — annuler l’opération, pas seulement le commit — est tout l’argument de Jujutsu, et après avoir lu le dossier du projet plutôt que son marketing, l’argument tient mieux que ses sceptiques le croient.

Le hub Undo Anything in Git de ce site existe parce que l’histoire de l’annulation chez git est fragmentée : reset, revert, reflog, chacun avec ses règles. Le pari de jj, c’est que cette fragmentation est un bug de conception.

C’est quoi Jujutsu, et pourquoi le comparer à git ?

jj est un système de gestion de versions compatible Git : 31 796 étoiles GitHub, 376 contributeurs, première version en décembre 2020, et une nouvelle release chaque mois depuis — de la v0.35 en novembre 2025 à la v0.45.1 en septembre 2026, douze releases qui atterrissent dans la première semaine du mois, métronome. Son dernier commit a été poussé le matin même de la publication de ce billet.

« Compatible Git » est la partie qu’on oublie. jj utilise un dépôt Git comme backend de stockage par défaut — le README le dit explicitement : les commits et les fichiers vivent au format git, donc votre clone, vos remotes, vos forges et votre CI continuent de fonctionner. La question jujutsu vs git que tout le monde tape est le mauvais angle : jj est plus proche d’une nouvelle interface branchée sur le stockage auquel vous faites déjà confiance. Le Sapling de Meta a fait le pari inverse avec son propre backend de stockage — c’est pourquoi passer à lui veut dire laisser derrière davantage de l’écosystème git.

Que fait le journal d’opérations que git ne fait pas ?

C’est le choix de conception qui vaut toute cette revue. Git enregistre les commits dans le reflog — le travail abandonné par accident reste récupérable pendant environ 90 jours. Mais le reflog ne se soucie pas de la séquence de commandes qui a produit le gâchis. La décision revert-vs-reset existe parce que git vous oblige à choisir la bonne commande d’annulation avant de savoir laquelle il vous fallait.

jj enregistre chaque opération — chaque rebase, chaque abandon, chaque squash — dans un journal d’opérations. La ligne du README : « parce que tout est enregistré, vous pouvez annuler l’erreur que vous venez de faire, aisément. » jj op log affiche l’historique de l’état du dépôt, et jj undo y revient pas à pas. Mauvais rebase ? Undo. Reset au mauvais endroit ? Undo. L’outil s’étend à ses propres actions la même sécurité que git étend à vos données.

L’histoire d’annulation de git suppose que vous choisirez la bonne commande. Celle de jj suppose que non.

Les conflits sont-ils vraiment des objets de premier rang ?

Oui, et ça change les flux d’équipe plus que l’histoire d’annulation. Git traite un conflit de fusion comme un état temporaire du répertoire de travail — on le résout maintenant ou on abandonne. jj stocke les conflits comme des objets dans l’historique : un commit en conflit peut exister, être commité, même être poussé. Résolvez le conflit plus tard et jj propage la résolution à tous les descendants automatiquement — le même mécanisme qui rebase votre pile quand vous modifiez un commit ancien.

Le résultat sur un vrai projet — des changements empilés qui se rebasent tout seuls — c’est ce qui convertit. Tiré du fil Hacker News sur les patterns jj (236 points) :

« Les PR empilées avec des rebases multi-branches deviennent triviaux. Les conflits sont de vraies choses dans l’historique qu’on peut reprendre plus tard. Tout est commité automatiquement, donc je ne perds pas de travail à cause d’un mauvais reset/stash pop. » — hellcow

C’est la dernière phrase qu’il faut garder. La copie de travail de jj est elle-même un commit, amendé à chaque changement. Pas de stash, parce qu’il n’y a rien à stasher — changer de branche emporte votre travail en cours comme un commit. Un autre commentateur, passé à jj au travail dans une équipe 100 % git : « il y a eu 0 problème. »

Que dit le dossier contre jj ?

Le registre honnête, parce que le dossier en a un :

• Version 0.x, assumée. Douze releases mensuelles, c’est aussi douze chances par mois de changements cassants. Le projet avance vite et le dit.
• Les bookmarks vivent hors de git. Les commits et fichiers passent par le stockage git ; les métadonnées de branches utilisent le format propre de jj. Les clones colocalisés font le pont, mais c’est une pièce de plus à comprendre.
• 1 262 issues ouvertes. Projet en bonne santé, vrai backlog.
• Le sceptique a encore raison sur un point. La réserve la plus votée du fil HN : « J’ai lu sur jj tant de fois maintenant que je suis toujours confus quant au problème qu’il résout. » Si votre flux git tient en une branche et une fusion de temps en temps, le journal d’opérations ne changera pas votre semaine. Les gains arrivent avec le travail empilé, les historiques conflictuels et les journées à annulations — les jours où le générateur git undo prend du trafic.

Faut-il passer de git à jj ?

Le verdict du dossier, avec la ligne d’honnêteté obligatoire : j’ai lu le dossier, je ne l’ai pas exécuté. Chaque chiffre et chaque citation vient du dépôt, de son README et du fil HN public — pas de mon terminal.

Ce que le dossier soutient : essayez jj colocalisé sur un projet perso — un clone, deux outils, zéro migration. Votre connaissance de git se transfère, puisque les objets du dessous sont ceux de git. Les équipes peuvent l’adopter personne par personne, puisque jj pousse des commits git ordinaires en amont. Ce que le dossier ne soutient pas : une migration big-bang d’une équipe installée, ou confier un outil 0.x à l’automatisation critique avant une période d’essai épinglée.

L’écart d’annulation est réel et la conception cohérente ; l’interopérabilité retire l’excuse habituelle, ce qui laisse l’habitude comme dernier obstacle.

Échangeriez-vous un week-end de mémoire musculaire contre un journal d’annulation qui couvre l’outil lui-même ? Et franchement — la dernière fois que vous avez perdu du travail sur un reset, le reflog a-t-il tout récupéré ?