jj – Le CLI de Jujutsu

• jj, l’interface en ligne de commande de Jujutsu, est un outil fondé sur un système de gestion de versions distribué (DVCS)
• Il offre des fonctionnalités plus simples, plus intuitives et pourtant plus puissantes que git
• Il combine les atouts de git et de Mercurial afin de réduire le nombre d’outils de base et de renforcer leur intégration organique
• Il utilise un backend compatible avec git, ce qui permet d’expérimenter de manière indépendante tout en conservant l’environnement de collaboration existant
• Pour les utilisateurs avancés, l’intérêt majeur est de pouvoir exploiter des fonctions supplémentaires de gestion de versions difficiles à obtenir avec git

---

Présentation et caractéristiques de jj

• jj est le CLI (interface en ligne de commande) de Jujutsu, et Jujutsu est un système de gestion de versions distribué (DVCS)

  • Les utilisateurs connaissent peut-être déjà d’autres DVCS comme git, et le tutoriel part du point de vue d’un utilisateur de git
  • jj a été conçu comme un outil plus simple, plus facile à utiliser et pourtant puissant que git
  • En général, « puissance » et « complexité » s’opposent, mais jj propose un nouvel équilibre
  • jj combine les points forts de git et de Mercurial (hg) pour former une nouvelle sorte de DVCS
  • Il réduit le nombre d’outils de base et offre un environnement de travail efficace grâce à l’intégration organique entre ces outils
  • Les utilisateurs avancés peuvent tirer parti de fonctions supplémentaires de gestion de versions difficiles à reproduire avec git
  • jj utilise un backend compatible avec git, ce qui permet d’expérimenter de manière indépendante sans modifier l’environnement de collaboration
  • Il reste compatible avec les dépôts git existants et permet, si nécessaire, de revenir facilement à git
  • Le tutoriel annonce qu’il montrera concrètement, à travers ces caractéristiques, pourquoi jj est un outil qui mérite l’attention

[GN⁺]

Commentaires sur Hacker News

• Beaucoup de discussions se concentrent sur les différences entre git et jj, mais je pense qu’il vaut mieux oublier git et se concentrer simplement sur le workflow de base de jj
  Dans un dépôt propre, il suffit d’exécuter jj pour voir l’état, puis après des modifications, de valider avec jj commit -m "made changes"
  En cas d’erreur, on corrige puis on fusionne dans le dernier commit avec jj squash
  On n’utilise jj new -r lmnop que lorsqu’on veut travailler à partir d’une révision précise, comme sur une nouvelle branche
  L’historique git reste visible avec git log, et le fonctionnement interne de jj n’apparaît pas

  • Je voulais quelque chose de similaire, donc j’ai créé un alias git comme alias.save="!git add -A; git commit -m", que j’utilise ensuite avec $ git save "made changes"

• J’ai l’impression que JJ me demande de penser à l’envers
  Avec git, on modifie puis on écrit le message de commit, alors qu’avec jj on crée d’abord un nouveau commit et on lui ajoute ensuite une description
  J’ai l’habitude de partir d’un état sale où plusieurs fonctionnalités sont mélangées, puis de ne sélectionner que les changements nécessaires pour les valider ; en ne regardant que le tutoriel jj, je ne suis pas sûr que ce soit possible

  • jj new correspond à une sorte de zone de staging git vide
    Dans jj, il y a toujours un commit, et ce commit a un changeid stable calculé à partir du contenu du dossier
    Si l’on veut répartir des changements en plusieurs commits, il suffit d’utiliser jj split
  • Moi aussi, j’utilise souvent jj new pour créer des commits temporaires en laissant le message vide
    Plus tard, quand tout est prêt, je squash plusieurs commits en un seul et j’ajoute le message
    Cette méthode fonctionne un peu comme un historique d’annulation, ce qui rend l’expérimentation bien plus confortable
  • En réalité, jj new signifie simplement « créer un nouveau commit au-dessus », donc il n’est pas nécessaire d’écrire une description tout de suite
    J’ai aussi essayé d’en prendre l’habitude au début, mais c’était au contraire inefficace
  • Dans JJ, cette façon de faire est standard
    Un workflow similaire est recommandé depuis longtemps dans Git, et on peut consulter le Squash Workflow pour obtenir un flux proche de l’index de Git
  • Moi aussi, quand je fais plusieurs changements, il m’arrive de mélanger différentes fonctionnalités
    Du coup, je garde plusieurs workspaces et j’utilise souvent la fonction shelve d’IntelliJ
    Parfois, je stocke aussi temporairement des diff sous forme de patch git
    Et j’essaie de cacher ce processus chaotique à mes collègues pour avoir l’air un peu plus professionnel

• Ce qui me déplaît avec jj, c’est que les modifications de fichiers sont automatiquement validées
  Si je fais un checkout d’un ancien commit pour l’explorer puis que je modifie des fichiers, ce commit est modifié et tout l’historique suivant est rebasé
  Du coup, je dois créer de manière défensive un nouveau commit vide
  Avec git, le dépôt ne change pas tant que je ne valide pas explicitement, ce qui me convient mieux

  • Je pensais pareil avant, mais j’ai changé d’avis après avoir découvert jj evolog
    jj avait déjà une solution meilleure que le staging
    Le fait d’être habitué à la CLI de git était au contraire un obstacle pour apprendre jj
    Fait intéressant, utiliser jj permet de mieux comprendre la structure du moteur de stockage de git
  • Si tu utilises jj new au lieu de edit, tu peux suivre les changements proprement
    J’ai trouvé ça bien meilleur que jongler avec le stash de git
  • jj edit est le plus gros piège de jj
    Mieux vaut utiliser jj new, et en cas d’erreur on peut récupérer avec jj undo
    jj traite les commits comme des snapshots peu coûteux, donc il est plus logique de se concentrer sur les « changements » que sur les commits
    Le rebase automatique devient immuable après le push, donc c’est sûr
  • Le fait que les modifications de fichiers soient automatiquement commit est une fonction centrale de jj
    Il suffit de combiner jj new et jj squash pour le gérer comme une tête de branche git
    jj facilite le travail en état de detached head
  • Tu sembles sans doute avoir fait un checkout d’un ancien commit avec jj edit
    En passant à jj new, le problème disparaît

• Le dernier paragraphe sur jj est l’essentiel
  Il utilise un backend entièrement compatible avec git, donc on peut l’essayer seul sans devoir faire migrer toute l’équipe
  Et si ça ne plaît pas, on peut revenir à git à tout moment

  • Sauf dans les organisations qui utilisent LFS, les submodules ou des hooks
  • Ce n’est pas une compatibilité totale. L’interopérabilité existe, mais ce n’est pas parfaitement fluide
    Les opérations git ne sont pas enregistrées dans le log jj, donc il faut les importer manuellement
    Sur un projet, il est conseillé de n’utiliser qu’une seule interface
  • Avant, j’utilisais déjà git comme ça avec CVS et Subversion
  • Mais utiliser git et jj en même temps dans le même répertoire peut casser les choses

• Ma fonctionnalité préférée est jj absorb
  Elle déplace automatiquement les changements de la révision courante vers les commits antérieurs concernés
  C’est pratique quand on a oublié de modifier un fichier de config ou .gitignore
  Il suffit de faire jj new, d’effectuer les modifications, puis jj absorb
  Et surtout, le meilleur, c’est qu’il n’y a pas besoin de gérer de merge conflict

  • Si jj absorb s’applique mal, on peut revenir en arrière avec jj undo
    Grâce à cette fonction, même les rebase complexes ne font plus peur
  • Pour information, il existe aussi git absorb dans git

• Je n’ai pas pu mettre le tutoriel à jour depuis longtemps, mais j’utilise toujours jj tous les jours
  J’ai été trop occupé avec la startup ersc.io pour travailler sur l’upstream
  Les questions sont toujours les bienvenues

  • La clé, c’est la différence d’immuabilité du DAG entre git et jj
    jj utilise des change ID stables, tandis que git utilise des commit ID immuables
    C’est pour cela que dans jj, undo et rebase semblent beaucoup plus flexibles
  • jj masque automatiquement les changements « sans intérêt »
    Il m’arrive parfois d’avoir envie d’en voir davantage ; je me demande s’il existe une option pour tous les afficher d’un coup

• jj est suffisamment différent de git pour mériter d’être essayé
  Le simple fait d’expérimenter une autre approche permet d’élargir sa vision de l’ingénierie
  Il n’est pas nécessaire de tout essayer, mais il est important de comprendre les trade-offs entre différents workflows

  • Bien sûr, dans 99 % des cas, des essais au gain marginal peuvent aussi être une perte de temps

• La relation entre git et jj me fait penser à celle entre C et Python
  git relève de la traçabilité forensique, tandis que jj ressemble à des chapitres d’une histoire
  Parfois, il faut réécrire les premiers chapitres pour que la suite soit plus naturelle

  • Ce que fait jj est aussi possible dans git, mais les réflexes de pensée hérités de git gênent
    jj a été conçu autour de l’idée que « l’arbre de travail lui-même est un commit » et que « même un conflit peut être commité »

• J’ai l’impression que l’affirmation « plus puissant et plus simple » a besoin d’exemples concrets

  • Pour citer quelques avantages de jj :
    • il n’est pas nécessaire de résoudre immédiatement les conflits de rebase/merge
    • la manipulation des commits est très simple, surtout avec jjui
    • jj dispose d’un operation log qui suit les changements d’état de git
    • les branches sans nom permettent de travailler librement sur des expérimentations
    • il est entièrement compatible avec git, ce qui permet un usage mixte au sein d’une équipe
  • Nous avons ressenti une grande amélioration en passant de SVN à git, mais aujourd’hui notre workflow git ne nous pose pas de gros problèmes
  • On peut travailler sur plusieurs PR en même temps dans un même dépôt et pousser chacune séparément selon les besoins
    Si l’on n’a pas ce besoin, on peut ne pas percevoir l’intérêt de jj
  • L’attrait de jj ne tient pas aux commandes, mais à son workflow intuitif
    Il faut l’utiliser soi-même pour comprendre
  • Rien que jj undo suffit à justifier sa valeur
    Avec git, on arrive facilement dans un état irrécupérable, alors qu’avec jj quelques undo suffisent pour s’en sortir

• Grâce à jj, je me sens plus à l’aise pour exploiter un DAG non linéaire
  Je manipule librement des changements avec plusieurs parents ou enfants
  Avant, j’imposais inutilement un ordre, mais maintenant je peux exprimer clairement les dépendances
  Le processus de revue et de soumission est aussi bien plus efficace

  • Je me demande si vous utilisez un workflow mega-merge + absorb au-dessus de ces changements ramifiés