Le tutoriel Jujutsu d’Evan

• Un tutoriel conçu pour permettre aux personnes ayant déjà utilisé Git d’apprendre rapidement le système de gestion de versions Jujutsu (jj), simple mais puissant
• Fournit un article de présentation de Jujutsu séparé pour les lecteurs qui souhaitent comprendre pourquoi utiliser Jujutsu avant de commencer
• Oriente aussi vers des alternatives adaptées au niveau des lecteurs, comme un guide d’introduction au ton conversationnel, une documentation officielle détaillée ou des ressources pour débutants en gestion de versions
• Rédigé directement par Evan Martin, qui a soigneusement choisi les sujets à inclure ou à omettre, ainsi que leur ordre de présentation
• Le corps du texte n’a pas été rédigé avec l’IA ; celle-ci n’a été utilisée qu’après la rédaction de la majeure partie du contenu, pour vérifier les erreurs

---

Public visé et parcours d’apprentissage

• Jujutsu est un système de gestion de versions simple mais puissant ; dans le tutoriel, il est ensuite désigné par jj
• Il propose un parcours d’apprentissage concis, centré sur l’essentiel, destiné aux lecteurs familiers de Git
• Pour commencer directement, vous pouvez aller à Démarrer le tutoriel ; pour comprendre d’abord les raisons de l’adopter, consultez l’article de présentation de Jujutsu

Ressources alternatives selon les lecteurs

• Si l’approche de ce tutoriel ne vous convient pas, vous pouvez choisir parmi les ressources suivantes selon votre niveau d’expérience et vos préférences
  • Steve's Jujutsu tutorial : la ressource d’introduction la plus recommandée, rédigée dans un style conversationnel
  • Jujutsu documentation : propose un tutoriel officiel qui aborde davantage de détails dès le départ
  • Jujutsu for Everyone : destiné aux lecteurs sans expérience préalable en gestion de versions

Rédaction directe et périmètre d’utilisation de l’IA

• L’ensemble du texte a été rédigé directement par Evan Martin ; les choix de contenu, d’omissions et d’ordre de présentation ont été soigneusement décidés par une personne
• L’IA n’a pas été utilisée pour produire le texte ; elle n’a servi qu’à vérifier les erreurs après la rédaction de la majeure partie du contenu

[GN⁺]

Avis sur Lobste.rs

• Franchement, au risque d’engager ma réputation, j’ai essayé jj pendant environ une semaine, mais j’ai fini par demander de l’aide à un LLM pour réduire la douleur liée à la manipulation directe de Git, et je n’ai pas eu l’impression qu’il remplaçait suffisamment mon workflow existant.
  D’habitude, je n’utilise guère que git checkout, git add, git commit et git push, et je rencontre rarement les problèmes mentionnés dans les articles de promotion — index, stash, différents types de reset, rebase en cours, annulations incohérentes — et je n’utilise pas beaucoup les monorepos non plus.
  Je me demande quel est le public principal de Jujutsu, et combien de temps il vous a fallu pour devenir à l’aise avec jj; la prochaine fois, j’aimerais au moins investir autant de temps.

  • Je suis curieux de savoir quelles tâches, concrètement, vous demandez au LLM de vous aider à faire.
    Moi aussi, avec Git, j’ai tendance à éviter tout ce qui dépasse les opérations de base : au lieu de faire un stash puis de changer de branche, je reclonais le dépôt ailleurs; au lieu de ne sélectionner que les changements pertinents pour un commit, je commitais tout avec git add --all, ou bien j’annulais des changements dans l’éditeur avant de commiter puis je les réappliquais.
    J’avais un contexte qui facilitait mon adaptation à jj, car j’ai utilisé Mercurial pendant 7 ans au travail, mais désormais, repositionner des commits et gérer plusieurs changements est devenu simple, au point que je fais volontiers des opérations complexes que j’aurais autrefois contournées par réflexe.
  • Le point de vue change selon ce pour quoi on utilise un système de gestion de versions (VCS).
    Si l’on se contente de garder de temps à autre des instantanés d’un code développé de façon linéaire, ces commandes suffisent, et un VCS complet peut même être excessif : Dropbox pourrait faire l’affaire.
    Pour moi, un VCS est un outil de construction narrative qui montre comment j’ai pensé le code et ses couches; le lecteur principal, ce sont mes collègues, et le lecteur secondaire, c’est moi dans 10 ans. jj permet de gérer cela avec beaucoup moins de friction.
  • C’est tout à fait acceptable de demander de l’aide à un LLM; je l’ai fait aussi jusqu’à apprendre les commandes de base dont j’avais besoin.
    Pour acquérir les bases du vocabulaire et des fonctionnalités, j’ai lu quelques guides du début à la fin et je l’ai utilisé régulièrement pendant quelques jours sur des projets personnels; je suis alors devenu assez à l’aise pour les opérations de base, et ma façon de voir les VCS a aussi changé.
    Quand je fais un refactoring ou que je développe une grosse fonctionnalité, j’implémente d’abord jusqu’à l’objectif final, puis je découpe en petits changements faciles à relire et dont la justification est claire, comme « corriger tous les avertissements eslint », « refactorer pour exposer une fonction », « basculer l’appelant A vers la nouvelle fonction », « ajouter la nouvelle fonctionnalité ». jj split est parfait pour cela, et cette seule fonctionnalité suffit déjà à justifier l’utilisation de jj.
    À l’inverse, git stash est difficile à utiliser avec plusieurs stashes et comporte de nombreux pièges d’ergonomie dangereux, au point qu’on peut perdre le code sauvegardé en cas de conflit. Intégrer des retours de PR dans un commit bas, puis rebaser les commits ou PR au-dessus, surtout avec des PR empilées, est presque un cauchemar : il n’y a pas d’indication de progression, il est difficile de s’arrêter au milieu ou de reconstruire la pile. C’est pourquoi j’utilise encore Graphite pour gérer les PR empilées.
  • Le plus grand bénéfice que j’ai tiré de jj, c’est sa façon de gérer les rebase.
    Un doctorant en chimie organique avait développé pendant 4 ans une branche de travail pour ses articles sans jamais la merger ni la rebaser; elle avait des milliers de commits de retard sur main, et il devait la fusionner avant sa soutenance. Comme il y avait des conflits sur presque tous les commits, cela aurait pris une à deux semaines avec Git; si, le troisième jour, un bug urgent arrivait, il fallait interrompre le rebase, corriger le bug, puis reprendre depuis le début, et une fois terminé trois semaines plus tard, il fallait encore rebaser sur le main le plus récent.
    Dans jj, les conflits de merge sont des objets de première classe, que l’on peut résoudre quand on a le temps; on peut passer à un nouveau commit en cours de route pour corriger un bug urgent sans perdre l’avancement. J’ai pu terminer en une journée un rebase qui aurait pris une semaine avec Git, et une fois, après avoir repéré une série de 200 commits consécutifs qui, une fois fusionnés, ne changeaient rien, j’ai jeté en bloc, en moins d’une minute, un travail qui m’avait occupé deux jours à traiter des dizaines de milliers de lignes de conflits. Même pendant un rebase, on peut mettre à jour main et déplacer sa branche de travail au-dessus du main le plus récent.

• Pour quelqu’un comme moi, tellement habitué à Git que je ne cherche des commandes qu’occasionnellement, cet article est la première présentation de Jujutsu que j’ai trouvée intéressante.
  Les articles précédents commençaient surtout par « on peut échapper à l’horrible interface en ligne de commande de Git »; même si je comprends les particularités de Git et les difficultés des autres, ce genre de formulation me faisait considérer Jujutsu comme quelque chose qui ne me concernait pas, un peu comme les romans d’amour ou le bœuf vindaloo.

  • La raison pour laquelle il est difficile d’expliquer le plaisir de jj, c’est que des propriétés implicites que l’on croyait aller de soi dans tous les VCS ne sont en réalité pas présentes, et que les opérations atomiques sont beaucoup plus simples.
    Comme il est difficile de trouver une bonne accroche, on finit par tout résumer à « ce n’est pas Git », et moi non plus, je ne suis pas vraiment capable de l’expliquer correctement.
  • Avec Git, on peut résoudre presque tous les problèmes évoqués ici en utilisant l’interface graphique Sublime Merge et quelques commandes personnalisées.
    Contrairement à d’autres interfaces graphiques Git, elle suit autant que possible les vraies commandes Git, tout en remplaçant seulement la syntaxe obscure par des menus et des boutons; elle ne cache pas non plus les commandes correspondant à chaque action, mais les consigne dans la barre d’état. Si Sublime JJ sortait, je basculerais immédiatement.
  • La formule qui m’a donné envie d’essayer jj, c’était Git toujours en état de rebase interactif.