Je vois un avenir dans jj

• Le nouveau système de gestion de versions jj est un projet écrit en Rust, conçu pour compenser les limites de Git tout en permettant une adoption progressive
• En s’appuyant sur son expérience passée d’analyse du potentiel de croissance de Rust, l’auteur estime que jj présente un potentiel similaire en matière d’adéquation au marché, d’équipe spécialisée et de base d’utilisateurs
• jj reste compatible avec les dépôts Git tout en proposant un workflow plus simple, ce qui le rend particulièrement plus accessible aux développeurs peu familiers avec la structure interne de Git
• Son usage se répand déjà chez Google et Oxide, et une communauté passionnée ainsi qu’une équipe de développement dévouée sont en train de se former
• L’auteur rejoint ERSC, qui développe une plateforme de collaboration basée sur jj, avec l’intention de contribuer directement à la croissance de l’écosystème jj comme à l’époque des débuts de Rust

---

Pourquoi j’ai choisi Rust

• L’auteur s’est intéressé au langage après avoir vu sur Hacker News, à Noël 2012, la nouvelle “Rust 0.5 released”
  • À l’époque, il était développeur Ruby on Rails, mais il s’intéressait déjà depuis l’université aux compilateurs et à la programmation système
• Pour évaluer les chances de succès de Rust, il a pris en compte trois éléments : l’adéquation au marché, l’équipe de développement et la base d’utilisateurs
  • Il n’existait alors aucun langage crédible pour remplacer C/C++, et Rust proposait une approche innovante offrant la sécurité mémoire sans garbage collection
  • Mozilla soutenait le projet et prévoyait d’introduire Rust dans Firefox, ce qui laissait penser qu’une base d’usage réelle pourrait émerger
• L’ambiance bienveillante et collaborative de la communauté Rust a aussi constitué un facteur d’attraction
  • Par la suite, l’auteur a rédigé le tutoriel “Rust for Rubyists” et participé comme co-auteur à la documentation officielle

L’arrivée de jj

• jj (Jujutsu) n’est pas un langage de programmation, mais un nouveau système de gestion de versions (VCS) implémenté en Rust
  • Il est compatible avec Git et peut être adopté progressivement tout en continuant à utiliser les dépôts existants
• L’auteur a commencé à explorer jj sur recommandation de Rain, une développeuse dont les goûts techniques sont proches des siens
  • Rain a travaillé dans l’équipe de gestion du code source de Meta, et sa recommandation a donc été perçue comme un signal fiable
• En expérimentant jj pendant le week-end, il a lancé un projet de rédaction de tutoriel
  • Comme lors de son apprentissage de Rust, il a choisi d’organiser ses idées en écrivant
  • Au final, le tutoriel a reçu un accueil positif dans la communauté

Perspectives d’avenir pour jj

• L’auteur voit dans jj un schéma de croissance semblable à celui du Rust des débuts
  • L’adéquation au marché, les capacités de l’équipe et le potentiel de diffusion auprès des utilisateurs lui semblent tous prometteurs
• Du point de vue de l’adéquation au marché, Git conserve une position dominante, mais jj peut gérer directement les dépôts Git, ce qui permet une adoption partielle
  • Chez Oxide aussi, son usage s’est diffusé à partir de Rain, au point de susciter suffisamment d’intérêt pour créer un canal dédié
• jj est également utilisé en interne chez Google, ce qui est interprété comme un signal comparable à l’adoption de Rust par Mozilla
  • Même dans les grands monorepos de Google (basés sur le backend Piper), certains projets utilisent déjà jj, ce qui constitue une forme de preuve sociale (social proof)
• Il existe une courbe d’apprentissage, mais pour les utilisateurs peu familiers avec la structure interne de Git, jj offre au contraire une utilisation plus intuitive et plus simple
  • Les experts Git doivent s’adapter à de nouveaux concepts, tandis que les développeurs généralistes s’y habituent rapidement
• La communauté jj se développe dans une atmosphère passionnée et conviviale, qui rappelle celle des débuts de Rust

L’équipe et la communauté jj

• Le créateur, Martin, s’est consacré au développement de jj pendant de longues années ; récemment, le projet est passé d’un compte personnel à un compte d’organisation officiel, avec une gouvernance restructurée
• Les membres de l’équipe sont des experts disposant d’une solide expérience dans le développement d’outils de contrôle de source, ce qui leur donne de vrais atouts en matière d’orientation technique et de qualité
• La communauté grandit rapidement grâce à des retours actifs et à la collaboration, en recréant l’énergie positive de la communauté Rust des débuts

Nouveau défi : rejoindre ERSC

• L’auteur a décidé de quitter Oxide pour rejoindre la startup ERSC, qui développe une plateforme de collaboration basée sur jj
  • Oxide était un excellent lieu de travail, mais le désir de s’impliquer plus profondément dans l’écosystème jj a été le facteur décisif
• ERSC prévoit de construire une plateforme de collaboration pour développeurs au-dessus de jj, et l’auteur évoque le cas de GitHub, qui avait démarré sous la raison sociale Logical Awesome, pour illustrer ce stade initial similaire
• Après avoir terminé son travail chez Oxide, l’auteur compte faire une pause, puis se consacrer à la communauté jj et à l’achèvement du tutoriel
  • Il annonce davantage d’activité sur Discord, une série d’articles de blog et diverses contributions à la communauté
• Il considère 2025 comme un nouveau tournant et exprime sa gratitude de pouvoir relever un défi autour d’un projet qui le passionne vraiment

Conclusion

• L’auteur est convaincu que jj a le potentiel de reproduire la trajectoire de croissance de Rust
  • Sa compatibilité avec Git, la possibilité d’une adoption progressive, une équipe dévouée et une communauté active en sont les principales raisons
• jj pourrait dépasser le simple statut d’outil pour devenir une plateforme d’innovation dans la manière dont les développeurs collaborent
• Le parcours de l’auteur, commencé avec Rust, entre désormais dans un nouveau chapitre avec jj

[tujuc]

On l’a déjà vu plusieurs fois, mais il faudrait quand même y jeter un œil.

[GN⁺]

Avis Hacker News

• J’ai essayé sérieusement jj une ou deux fois. Le concept de conflits de première classe est cool, mais en pratique je fais bien plus souvent du staging/commit que de la résolution de conflits. Venir de magit fait que le découpage et la sélection de hunks dans jj me semblent très inconfortables. Je rebase souvent, donc avec les raccourcis de rebase de magit, je profitais déjà de la plupart des avantages de jj. Pour quelqu’un comme moi, jj devra nettement améliorer l’UX de sélection des hunks pour surpasser magit

  • L’essentiel avec jj, c’est justement de ne pas penser en termes de staging ou de commit. Tout est un changement (change), et il faut raisonner en marquant le parent ou des ancêtres plus lointains avec un bookmark pour les squash dedans, ou en déplaçant le bookmark vers le changement suivant
  • Moi aussi je rebase souvent, mais la philosophie de gestion de versions très prescriptive de jj ne me plaît pas. Surtout pour les débutants, je pense que trop masquer l’architecture interne n’aide pas à apprendre
  • Je me demande concrètement à quoi ressemble l’UX de sélection des hunks dans magit. Ça ne m’a pas semblé très différent de celle de jj. J’ai longtemps utilisé GitUp(gitup.co), et même si l’UX de jj n’est pas totalement naturelle, ça me paraît être un problème réglable via la personnalisation des raccourcis
  • Si on comprend pourquoi il est important d’ajouter une bonne UX par-dessus Git, on a déjà compris 95 % de la philosophie de jj
  • On peut aussi utiliser l’index Git avec jj. Il faut simplement éviter les commandes jj qui modifient git_head. J’utilise un alias pour commit les changements staged (exemple de config.toml)

• Chaque fois que je vois une alternative à Git, j’ai un léger réflexe luddite. Il y a déjà trop de langages, frameworks et outils. Au moins pour les VCS, je trouve rassurant d’avoir Git comme solution quasiment universelle. jj résoudra peut-être des problèmes, mais vu la charge pour le secteur de devoir supporter deux systèmes, je ne suis pas sûr que le bilan soit positif

  • L’interface médiocre de Git m’agace tellement que j’espère qu’il sera remplacé. J’aimerais voir un nouvel outil qui explique mieux les concepts de Git
  • jj est une option que chaque développeur peut choisir individuellement. Un dépôt jj est un sur-ensemble d’un dépôt Git, donc les outils existants ne cassent pas
  • J’ai déjà travaillé dans une entreprise qui utilisait svn, où nous sommes d’abord passés à Git via git-svn. jj semble suivre une approche similaire. Même sans connaître jj, la CI et les outils existants continuent de fonctionner
  • Git est un frein à la productivité, et c’est encore plus problématique à l’ère du code piloté par agents. Je ne trouve pas jj assez révolutionnaire. Il faudrait plutôt un nouveau VCS qui suive les changements de manière atomique (atomic). Avec une telle structure, la notion de branche disparaîtrait, et l’état du dépôt pourrait être composé à partir de plans et d’atomes. Cela dit, basculer vers un tel système serait un défi immense
  • Comme git est arrivé après rcs, cvs et svn, il finira lui aussi un jour par être remplacé par quelque chose de meilleur

• J’ai essayé jj, mais je suis habitué à Sublime Merge. Faire de la gestion de versions en CLI implique beaucoup de saisie répétitive et il est facile de perdre le fil de l’état courant. Avec une GUI, l’état reste toujours visible, et un clic suffit pour voir un diff ou saisir un message de commit. Je n’ai plus jamais envie de sélectionner des hunks au clavier. SM est vraiment agréable. J’aimerais que la GUI de jj progresse, ou que jj soit intégré à SM

• La vraie nouvelle, c’est que des gens ont commencé à créer des choses comme « jjhub » (ersc.io)

  • Je pense que « jjhub » est une bonne première étape. On peut déjà utiliser jj avec GitHub, mais il faudra proposer quelque chose de réellement utile au-delà de ça
  • À noter qu’il y a aussi ceci : article de blog sur Stacking
  • Gerrit est aussi très compatible avec les concepts de jj, et une RFC ajoutant le support des change ID de Jujutsu a été approuvée
  • Le nom jjhub est franchement réussi
  • J’espère sincèrement que ça marchera. Il est temps qu’apparaisse une vraie alternative à GitHub

• On dit que jj se diffuse en interne chez Google, mais Google a tendance à changer périodiquement de VCS interne. Wrapper Git, version étendue de Mercurial, et maintenant jj : tout a changé en l’espace de 7 ans

  • En réalité, la plupart des outils internes de Google ont une durée de vie courte. Malgré tout, jj est innovant parce qu’il préserve l’identité (identity) d’un changement. Avec Git, après un rebase ou un amend, cela devient un commit complètement différent, alors qu’avec jj, cela continue d’être suivi comme le même changement. Cela dit, jj continuera probablement à utiliser Git comme backend de stockage
  • J’espère que jj va durer. J’aimerais utiliser le même workflow au travail et à la maison. C’est bien plus rapide que Mercurial
  • Cette fois, on dirait qu’ils veulent aussi abandonner leur fork de Perforce. Vu de l’extérieur, ça fait vraiment beaucoup de changements
  • Le wrapper Git était à l’origine expérimental, et le système basé sur Mercurial a été maintenu pendant presque 10 ans

• Je me demande si jj gère mieux les gros fichiers binaires que Git. Dans le développement de jeux, Perforce reste toujours roi. Même avec LFS, Git ne suffit pas vraiment

  • En pratique, le support des binaires de Perforce est quasiment identique à Git LFS. La différence tient surtout au support entreprise
  • jj utilise Git comme stockage et ne prend pas en charge LFS, donc il a sur ce point les mêmes limites que Git
  • Pour l’instant, il n’y a pas d’amélioration particulière, mais le sujet est identifié et cela pourrait évoluer à l’avenir

• J’ai suivi le tutoriel Jujutsu pendant une journée environ, et j’ai trouvé ça plutôt bien. Mais j’avais l’impression qu’il manquait une pièce du puzzle. Par exemple, je me demandais si les change id étaient réellement utiles quand on ouvre une PR sur GitHub. J’imagine que cela révèle surtout sa vraie valeur avec le backend Piper interne à Google. Je suis curieux de voir le plan d’ERSC. Personnellement, je voudrais un workflow distribué avec revue de code hors ligne intégrée

  • Ravi que ça t’ait plu :) À l’heure actuelle, les avantages des change id sont presque nuls sur GitHub. Mais on peut retrouver une partie de l’expérience avec des outils comme jj-spr. Il y a aussi eu un tweet montrant que le SVP de GitHub s’intéresse à jj. Par ailleurs, j’ai testé beads, un système qui met les issues dans le dépôt, et ça m’a plutôt bien plu
  • Les commits créés par jj incluent un en-tête change-id, donc même si GitHub ne connaît pas jj, les utilisateurs de jj peuvent quand même suivre les rebases entre eux. On peut le vérifier avec git cat-file -p HEAD

• J’utilise jj sur des projets personnels depuis un à deux mois, et j’en suis assez satisfait. En revanche, lorsqu’on modifie une ancienne révision, un fichier nouvellement ajouté à .gitignore peut se retrouver inclus par erreur. À part ça, c’est bien. Cela dit, j’ai encore bien plus de connaissances sur Git, donc je compte l’introduire doucement aussi au travail

• J’ai rejoint cette année l’entreprise Sapling/Subversion, donc je n’ai pas encore essayé jj. Cela dit, Sapling est bien plus intuitif, et des piles de commits sont plus faciles à comprendre que des branches. Je me demande toutefois ce que ça donne sans un support comme l’interface de revue de Meta. Ce genre de projet est vraiment nécessaire

  • Oui, Sapling et jj sont des projets compagnons qui vont dans la même direction

• Quel que soit le nom, East River Source Control est vraiment un excellent nom