> Jujutsu v0.46, passé en revue : ce qui change et qui doit bouger▋

Il y a deux semaines, ce site lisait le record de jj pour la première fois et y voyait le bouton undo que git n'a jamais eu — 31 796 étoiles, des releases mensuelles, un journal d'opérations. Aujourd'hui, la deuxième lecture : 32 012 étoiles (+216 sur la quinzaine), la v0.46.0 sortie il y a six jours, et un dépôt poussé à 05:22 UTC ce matin, avant que la bouilloire ne soit branchée.

La ligne d'honnêteté, comme la dernière fois : j'ai lu le record, je n'ai pas exécuté l'outil. Tout ce qui suit vient des notes de release v0.46.0, du record public du dépôt et de notre première lecture. Ce qu'ajoute une deuxième lecture, c'est ce qu'une première ne peut pas avoir : un delta. Deux semaines de releases, deux semaines d'étoiles, deux semaines de nos propres données de recherche qui s'accumulent derrière la même question.

Et le mensonge que ce billet refuse : qu'un numéro de version soit une actualité. La plupart des point releases sont de la plomberie. La v0.46.0 ne l'est pas — elle change le calcul de la bascule, et les données de demande de la quinzaine expliquent pourquoi ça compte plus que le changelog ne l'admet.

Ce qui change dans Jujutsu v0.46 ? Les workspaces peuvent désormais se colocaliser via de vrais worktrees git (jj workspace add --colocate), jj undo/jj redo refusent par défaut les opérations cross-workspace, jj bisect run vérifie ses deux points de bout, et le git minimum passe à 2.42.0. Les dépôts colocalisés restent du git ordinaire pour GitHub et les coéquipiers.

Le record de la quinzaine

Les chiffres d'abord, parce que c'est la seule partie de ce billet que personne ne peut contester.

la mesure	première lecture (29 sept)	deuxième lecture (13 oct)
étoiles GitHub	31 796	32 012 (+216 / 14 jours ≈ 15/jour)
dernière release	v0.45.1 (3 sept)	v0.46.0 (7 oct — un écart de 34 jours)
dernière poussée du dépôt	active	05:22 UTC ce matin
issues ouverts	—	1 260

Les étoiles sont de la vanité, la cadence est le signal : deux releases en six semaines avec les breaking changes proprement listés, c'est un projet qui livre et qui dit ce qu'il casse. Les 1 260 issues ouverts se lisent pareil — un outil qui bouge, pas un outil fini.

Notre propre registre porte le second signal. La plus grosse famille d'impressions du cluster git ce mois-ci est toujours annuler un commit en gardant les changements — impressions en hausse de 100 % semaine après semaine, et presque aucun clic, parce que la réponse git honnête est enfouie à trois commandes de profondeur et les lecteurs le sentent. La demande d'undo n'a pas attendu jj. Elle n'attend jamais.

Jujutsu vs git : la table de l'undo

La première lecture expliquait le modèle — la copie de travail est un commit, chaque opération écrit dans le journal d'opérations, les conflits sont des citoyens de première classe. Ce qu'elle a sauté, et ce que les données de recherche disent que les gens cherchent réellement à 6h du matin, c'est la table au niveau des phrases : le travail, tapé comme les chercheurs le tapent, dans les deux dialectes.

le travail	git (l'incantation)	jj (l'opération)
annuler ma dernière action	reflog, l'œil plissé, reset --soft ou reset --keep	jj undo
annuler l'annulation	il n'existe aucun chemin propre	jj redo
voir ce qui vient de se passer	git reflog	jj op log
amender le dernier commit	git commit --amend	éditez les fichiers — le commit de copie de travail s'amende tout seul
garder un conflit pour plus tard	pas autorisé — résolvez maintenant ou arrêtez	les conflits sont des commits ; résolvez quand vous voulez

Dans git, l'undo est de l'archéologie — creuser le reflog, trouver le shard, reconstruire. Dans jj, la bande n'a jamais été enterrée : l'undo est une opération sur le journal des opérations. L'excavation contre un bouton de rembobinage.

imaginez : git vous donne l'enregistreur de vol — monté derrière l'avion, lisible après le crash. jj l'a monté sur le tableau de bord et l'a câblé à un bouton de rembobinage.

v0.46.0 : les deux changements qui comptent

Des workspaces qui se colocalisent via de vrais worktrees git. jj workspace add --colocate (ou le réglage git.colocate) place un workspace jj à côté d'un checkout git ordinaire sans prendre le clone en main. Lisez ça comme un embranchement qui s'élargit : une équipe peut faire tourner un workspace jj à côté d'un checkout git, sur la même machine, le même dépôt, et comparer — exactement l'essai que demandait le verdict de la première lecture. Il s'appuie sur git worktree add --orphan, d'où le git minimum qui passe à 2.42.0.

Un undo qui connaît ses limites. jj undo et jj redo refusent désormais de toucher aux opérations d'un autre workspace, sauf à passer --allow-cross-workspace. Un outil dont tout l'argument est « l'undo est sûr » qui resserre les gardes autour de l'undo, c'est le test de culture réussi. Le reste des notes se lit pareil : jj bisect run vérifie ses points bon et mauvais avant de marcher, et jj split arrête de jongler avec les sessions d'éditeur.

Essayer l'enregistreur sans rien risquer

Dans un clone jetable, lancez jj git init --colocate — un répertoire .jj apparaît à côté de .git, git continue de fonctionner exactement comme avant, et jj op log montre l'enregistreur tourner. Rien ne change côté git ; la porte de sortie est rm -rf .jj.

vérification : jj op log dans ce clone liste vos opérations avec horodatage — une ligne par commande, et le registre est réel sur votre machine, pas seulement dans la doc.

Le registre honnête : ce qui casse

La mémoire musculaire, d'abord. La danse de l'index — git add -p, le staging partiel — se traduit en squash et split de jj, qui règlent le même problème avec d'autres mains. La première semaine, vous taperez des verbes git et vous serez agacé.

L'optique d'équipe, ensuite. Les dépôts colocalisés ressemblent à du git ordinaire pour l'hébergement comme pour les coéquipiers — mais les commits de copie de travail d'un utilisateur jj ne deviennent visibles qu'au push, et « où est mon travail à moitié fini » reçoit une réponse différente de celle qu'attendent les gens de git. Les petites équipes haussent les épaules ; les monorepos au tooling profond devraient attendre. Le refus d'undo cross-workspace de la v0.46 est une limite de plus à apprendre — délibérément, et honnêtement, le bon choix.

Et le reçu toujours manquant : les benchmarks. Deux lectures plus tard, la prétention reste non formulée. Je ne peux pas vous dire que le rebase de jj bat celui de git sur un dépôt de 10 000 commits, parce que je ne l'ai pas exécuté — ce chiffre n'existe pas tant que le bench n'existe pas, et une deuxième lecture ne transforme pas une lecture de record en bench.

Verdict, révisé : qui doit bouger cette semaine

La première lecture disait : essayez-le. Deux semaines et une release plus tard, le calcul a bougé dans exactement une direction — la colocation worktree de la v0.46 a baissé le coût de l'essai lui-même, et les données de demande se sont durcies. La famille undo que suit notre tableau n'a pas refroidi d'une seule impression ; l'outil qui y répond en une commande a livré deux fois. Quand un écart aussi large continue de se creuser, quelqu'un va le combler. jj le comble au niveau du modèle, pas du moyen mnémotechnique — la comparaison complète est sur le hub git-undo, à côté de la décision classique qu'il dérange : revert vs reset, qui a désormais une troisième réponse, et la troisième réponse est un bouton.

Bougez maintenant : les développeurs solo et les petites équipes marquées par l'undo ; quiconque enseigne git et en a assez de voir les visages tomber au reflog ; et — la voie que nous surveillons le plus — les dépôts pilotés par des agents, où chaque opération devrait être réversible et auditable par défaut. Un journal d'opérations n'y est pas un confort ; c'est la surface d'audit que git n'a jamais livrée.

Attendez : les chaînes de tooling git profondes, les hypothèses de CI lourdes en hooks, quiconque est en pleine migration. Et attendez le bench — le prochain billet jj de ce site fera s'affronter jj et git sur un vrai dépôt et imprimera le chiffre le plus laid en premier, parce que le record de la quinzaine a acheté le bénéfice du doute exactement une fois.

Deux questions avant ce bench : un sauvetage par reflog vous a-t-il déjà lâché au pire moment — et si vous faites tourner jj pour de vrai ce mois-ci, qu'est-ce qui casse en premier ? Les commentaires sont ouverts ; dites-nous quoi tester.