Créer de meilleurs noms de branche de génération avec `jj`

• jj est un système de gestion de versions compatible avec Git qui recommande les branches anonymes, mais pour pousser vers un dépôt Git, un bookmark, c’est-à-dire un nom de branche Git, est nécessaire
• Par défaut, jj git push --change xyz crée une branche push-xyz ; c’est centré sur le change ID, donc naturel dans la CLI, mais dans la liste GitHub il est difficile de deviner le contenu du travail
• Il est possible d’améliorer cela en modifiant le template git_push_bookmark pour transformer la première ligne de la description en slug court avec slugify(), puis d’y ajouter un change ID court
• jj git push --change ozkspkuyzpwu crée alors add-note-about-jj-bookmark-templates/ozkspkuyzpwu, ce qui conserve à la fois la lisibilité et le lien avec la révision
• Dans un dépôt partagé, on peut ajouter devant un namespace comme ddbeck/, mais les règles de nommage des branches Git sont complexes et, si le nom est invalide, il faut créer le bookmark manuellement

---

Améliorer les noms de branche Git push de jj

• jj (Jujutsu) est un système de gestion de versions compatible avec Git qui, pour plusieurs raisons, suppose et recommande l’usage de branches anonymes
• Lors d’un push vers un dépôt Git, même une branche anonyme a besoin d’un nom ; dans jj, cela s’appelle un bookmark, et dans Git une branch
• jj git push --change xyz pousse la révision dont l’ID est xyz vers la branche Git push-xyz
• La valeur par défaut est naturelle dans la mesure où elle met en avant le change ID, souvent affiché et utilisé par la CLI de jj, mais dans la liste des branches sur le site GitHub, il est difficile de se rappeler à quoi correspond push-xyz

Méthode de modification de la configuration

• Créez un nouvel alias de template template alias slugify() et modifiez le template git_push_bookmark pour qu’il l’utilise

[template-aliases]
"slugify(str)" = '''
truncate_end(
65,
str.first_line()
.replace(regex:'[^[[:alnum:]].]', '-')
.replace(regex:'-{2,}', '-')
.replace(regex:'\.{2,}', '.')
.replace(regex:'(^-+|-+$)', '')
.lower()
)
'''
[templates]
git_push_bookmark = 'slugify(description) ++ "/" ++ change_id.short()'

• slugify() utilise la première ligne de la description du changement pour créer un nom court au format slug, puis y ajoute à la fin un change ID court
• Par exemple, si vous exécutez jj git push --change ozkspkuyzpwu, cela crée add-note-about-jj-bookmark-templates/ozkspkuyzpwu
• Ce nom est plus lisible tout en conservant le lien avec l’ID de révision affiché dans la CLI de jj
• Si vous poussez vers un dépôt partagé avec d’autres personnes, vous pouvez modifier le template pour placer vos branches dans un namespace distinct

[templates]
git_push_bookmark = '"ddbeck/" ++ slugify(description) ++ "/" ++ change_id.short()'

• Rien ne garantit que le nom de branche Git sera toujours sûr
• Les règles de validité des noms de branche Git sont complexes ; si le template génère un nom invalide, une erreur se produit et il faut créer le bookmark manuellement

[GN⁺]

Avis sur Lobste.rs

• J’utilise assez efficacement une approche qui consiste à inclure et exploiter des métadonnées dans les messages de commit
  Je crée d’abord un alias trailer_v(key) pour extraire facilement les valeurs de trailer depuis la description du commit, puis je construis dans un script de push nushell un label de branche au format ticket/topic avec jj log
  Par exemple, si le message de commit contient ticket:TKT-123 et topic:stop-crashing, le script qui pousse vers GitHub et ouvre la page "Create PR" récupère ces valeurs et les utilise
  Les Git trailers sont pratiques comme stockage clé-valeur cohérent dans la description, mais il reste actuellement un peu fastidieux de les extraire dans le langage revset

• Générer un slug de nom de branche à partir du message de commit ou du contenu des modifications semble être un domaine que les LLM locaux peuvent traiter facilement

  • Je me demande s’il y a vraiment une raison d’utiliser un LLM. Le simple script présenté dans l’article est plus léger, probablement plus rapide, et fonctionnerait presque aussi bien

• Il est arrivé plusieurs fois qu’un collègue me demande à propos des noms de branche générés automatiquement par jj
  Je pense essayer une variante de cette approche pour des branches de commit ponctuelles

• Un nom de branche basé sur le change-id me paraît parfait. Je n’ai pas envie de le changer
  Ce n’est qu’un nom de branche exigé par un outil de revue de code horrible, pas un titre

  • Les noms de branche générés automatiquement par défaut me conviennent globalement aussi, mais quand on pousse un lot de changements pour en faire des PR, il peut être difficile de savoir quelle PR doit cibler quelle branche
    On pourrait aussi résoudre ça avec un outil qui automatise la création des PR, mais cette approche a l’avantage d’être simple
  • Chez $JOB, utiliser des noms de branche descriptifs est la convention