Mit `jj` bessere Namen für Generierungs-Branches erstellen

• jj ist ein Git-kompatibles Versionsverwaltungssystem, das anonyme Branches empfiehlt. Für ein push in ein Git-Repository wird jedoch ein Bookmark, also ein Git-Branch-Name, benötigt.
• Das Standardverhalten von jj git push --change xyz erstellt den Branch push-xyz. Das ist auf die Change ID zentriert und in der CLI naheliegend, in GitHub-Listen aber wenig aussagekräftig.
• Durch Anpassen des Templates git_push_bookmark lässt sich die erste Zeile der Beschreibung mit slugify() in einen kurzen Slug umwandeln und anschließend eine kurze Change ID anhängen.
• jj git push --change ozkspkuyzpwu erzeugt dann add-note-about-jj-bookmark-templates/ozkspkuyzpwu und bewahrt so sowohl gute Lesbarkeit als auch die Verknüpfung zur Revision.
• In gemeinsam genutzten Repositories kann man vorne einen Namespace wie ddbeck/ ergänzen. Da die Regeln für Git-Branch-Namen jedoch komplex sind, muss man bei ungültigen Namen gegebenenfalls ein manuelles Bookmark anlegen.

---

Bessere Branch-Namen für Git-Pushes in jj

• jj(Jujutsu) ist ein Git-kompatibles Versionsverwaltungssystem und erwartet bzw. empfiehlt aus mehreren Gründen die Nutzung anonymer Branches.
• Beim push in ein Git-Repository brauchen auch anonyme Branches einen Namen. In jj heißt das Bookmark, in Git heißt es Branch.
• jj git push --change xyz pusht die Revision mit der ID xyz auf den Git-Branch push-xyz.
• Der Standardwert ist naheliegend, weil er die Change ID betont, die in der jj-CLI häufig angezeigt und verwendet wird. In der Branch-Liste auf der GitHub-Website ist bei push-xyz jedoch schwer zu erkennen, worum es inhaltlich geht.

So funktioniert die Konfigurationsänderung

• Es wird ein neues Template-Alias slugify() angelegt und das Template git_push_bookmark so geändert, dass es dieses verwendet.

[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() verwendet die erste Zeile der Änderungsbeschreibung, um einen kurzen Namen in Form eines Slugs zu erzeugen, und hängt am Ende die kurze Change ID an.
• Wenn man zum Beispiel jj git push --change ozkspkuyzpwu ausführt, wird add-note-about-jj-bookmark-templates/ozkspkuyzpwu erzeugt.
• Dieser Name ist besser lesbar und behält zugleich die Verbindung zur Revisions-ID, die in der jj-CLI angezeigt wird.
• Wer in ein Repository pusht, das mit anderen geteilt wird, kann das Template so ändern, dass die eigenen Branches unter einem separaten Namespace abgelegt werden.

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

• Es ist nicht garantiert, dass Git-Branch-Namen immer sicher sind.
• Die Regeln für gültige Git-Branch-Namen sind komplex. Wenn das Template einen ungültigen Namen erzeugt, tritt ein Fehler auf und das Bookmark muss manuell erstellt werden.

[GN⁺]

Lobste.rs-Kommentare

• Ich nutze recht erfolgreich einen Ansatz, bei dem ich Metadaten in Commit-Messages einfüge und auswerte
  Zuerst lege ich ein Alias trailer_v(key) an, um Trailer-Werte bequem aus der Commit-Beschreibung zu holen, und im nushell-Push-Skript baue ich dann mit jj log ein Branch-Label im Format ticket/topic zusammen
  Wenn ich zum Beispiel ticket:TKT-123 und topic:stop-crashing in die Commit-Message schreibe, verwendet ein Skript, das zu GitHub pusht und die Seite "Create PR" öffnet, genau diese Werte
  Git-Trailer sind dafür praktisch, weil sie ein konsistenter Key-Value-Speicher innerhalb der Beschreibung sind, auch wenn es im aktuellen revset-Sprachumfang noch etwas umständlich ist, sie auszulesen

• Das Slugifizieren von Branch-Namen auf Basis von Commit-Messages oder Änderungen wirkt wie ein Bereich, den ein lokales LLM leicht übernehmen könnte

  • Ich frage mich allerdings, ob man dafür überhaupt ein LLM braucht. Das einfache Skript aus dem Artikel ist schlanker, vermutlich schneller und dürfte fast genauso gut funktionieren

• Teammitglieder haben mich schon mehrfach nach den von jj automatisch erzeugten Branch-Namen gefragt
  Für einmalige Commit-Branches werde ich wahrscheinlich eine Variante dieses Ansatzes ausprobieren

• Branch-Namen auf Basis der Change-ID wären für mich ideal. Ich würde sie eigentlich gar nicht ändern wollen
  Das ist nur ein von schrecklichen Code-Review-Tools geforderter Branch-Name, kein Titel

  • Mit den standardmäßig automatisch erzeugten Branch-Namen bin ich im Großen und Ganzen auch zufrieden, aber wenn man mehrere Änderungen pusht und daraus PRs macht, kann es verwirrend werden, welchem Branch welcher PR zugeordnet werden soll
    Das ließe sich wohl auch mit einem Tool zur Automatisierung der PR-Erstellung lösen, aber dieser Ansatz ist angenehm einfach
  • Bei $JOB sind beschreibende Branch-Namen die übliche Konvention