jj v0.43.0 veröffentlicht

• Das Git-kompatible Versionsverwaltungssystem jj v0.43.0 ergänzt jj run, um Befehle auf mehrere Changesets anzuwenden und wiederholte Prüf- und Korrekturaufgaben stärker zu automatisieren
• jj run nutzt für jedes Changeset eine dedizierte Arbeitskopie und propagiert auch Änderungen sowie Konflikte von Befehlen, die die Arbeitskopie verändern, etwa cargo check oder cargo fix
• Dieses Release enthält Änderungen, die bestehende Konfigurationen und die Nutzung von Revsets betreffen, darunter die Entfernung von git_head(), git_refs(), Git-artiger Symbolauflösung und ui.revsets-use-glob-by-default
• Ebenfalls hinzugekommen sind jj show --reversed, die Suche nach Konfigurationen in /etc/jj, jj config gc, jj gerrit upload -o, die Revset-Funktion forks() sowie Farbstile für durchgestrichenen Text
• Behoben wurden Probleme bei der Datei-Identity-Verarbeitung unter Windows, Snapshots unveränderlicher Arbeitskopien, Warnungen bei doppelten Remote-URLs sowie Beschädigungen loser Git-Objekte auf Intel Raptor Lake und aarch64

---

Release-Überblick

• jj ist ein einfaches und zugleich leistungsfähiges Git-kompatibles Versionsverwaltungssystem
• In v0.43.0 kommt neu jj run hinzu, um Befehle auf mehrere Changesets anzuwenden
• Hinweise zur Installation für den Einstieg finden sich in den installation instructions

Befehle je Changeset ausführen: jj run

• jj run kann denselben Befehl auf mehrere Changesets anwenden
• Jedes Changeset verwendet eine voneinander getrennte dedizierte Arbeitskopie
• Der ausgeführte Befehl kann die Arbeitskopie aktualisieren; daraus entstehende Änderungen und Konflikte werden passend propagiert
• Beispiele:
  • jj run -- cargo check --all-features
  • jj run -- cargo fix

Entfernte Funktionen mit Auswirkungen auf die Kompatibilität

• Die in Revsets und Templates nicht mehr verwendeten Funktionen git_head() und git_refs() wurden entfernt
• Git-artige Symbole wie refs/heads/main werden nicht mehr als Revisionen aufgelöst
  • Stattdessen muss die Syntax <name> oder <name>@<remote> für Bookmarks/Tags verwendet werden
• Auch die nicht mehr verwendete Option ui.revsets-use-glob-by-default wurde entfernt
• jj bookmark track und untrack unterstützen das Muster <kind>:<bookmark>@<remote> nicht mehr
  • Die Symbolsyntax <bookmark>@<remote> wird weiterhin unterstützt
  • Zugehöriges Issue: #9226

Neue Funktionen

• jj show unterstützt das Flag --reversed
• jj sucht Konfigurationsdateien nun auch in /etc/jj
• jj config gc bereinigt Konfigurationen von gelöschten oder verschobenen Repositories im Ordner ~/.config/jj/repos
  • Zugehöriges Issue: #9362
• jj gerrit upload unterstützt die Flags -o / --option, die sich wie git push -o bzw. --push-option verhalten
• jj git fetch rebaset anhand der Change-ID die Nachfolger-Revisionen neu geschriebener Revisionen
  • Zuvor wurden eine neu geschriebene Revision und ihre Nachfolger-Revisionen nicht immer rebased, wenn in einem Stack mehrere Revisionen mit Bookmarks versehen waren
  • Unveränderliche Nachfolger-Revisionen werden nicht rebased
• Die Revset-Funktion forks() wurde hinzugefügt
  • Sie gibt alle Commits zurück, die mindestens zwei Kinder haben
• Die Einstellung colors unterstützt mit { crossed-out = true } einen Textstil für durchgestrichenen Text

Behobene Probleme

• Unter Windows werden beim Abfragen der Datei-Identity eines Pfads keine symbolischen Links mehr verfolgt
  • Das Verhalten entspricht damit Unix
  • Zuvor wurden zwei symbolische Links, die auf dasselbe Ziel zeigten, als dieselbe Datei behandelt
  • Diese Identity-Prüfung wird verwendet, um beim Schreiben der Arbeitskopie Aliase für die reservierten Verzeichnisse .git und .jj zu erkennen
  • Zugehöriges Issue: #8924
• Wenn die Arbeitskopie unveränderlich war, erstellt jj während des Snapshots eine neue Working-Copy-Revision
  • Zuvor wurde direkt nachdem die Arbeitskopie unveränderlich geworden war eine neue Revision erstellt
  • Zugehörige Issues: #7751, #9338
• jj git remote add warnt, wenn die Fetch-URL oder die effektive Push-URL eines neuen Remotes exakt mit der eines bestehenden Remotes übereinstimmt
  • Zugehöriges Issue: #413
• Auf Intel-Raptor-Lake-CPUs und aarch64 wurde ein Problem mit beschädigten losen Git-Objekten behoben
  • Zuvor meldete jj einen erfolgreichen Commit, doch ein späteres git fsck konnte mit incorrect data check, corrupt loose object oder missing blob fehlschlagen
  • Spätere jj-Operationen konnten außerdem mit corrupt deflate stream fehlschlagen

[GN⁺]

Meinungen auf Lobste.rs

• Ich freue mich sehr auf jj run.

• Ich finde es gut, dass die Deprecation zurückgenommen wurde für jj bookmark track/untrack <name>@<remote>
--remote jedes Mal einzutippen, war immer eher unschön.

• Dass beschädigte loose Git-Objekte auf Intel Raptor Lake CPU und aarch64 behoben wurden, klingt nach einem interessanten Bug.
  Falls es dazu einen Blogbeitrag gibt, würde ich ihn gern lesen 😃

• Bisher dachte ich, alle beschädigten Git-Objekte, die ich gesehen hatte, seien auf Dateisystem-Rollbacks zurückzuführen gewesen.
  Ein f2fs-Rollback nach einem harten Shutdown erzeugte mitunter ziemlich interessante Plattenzustände; daher ist es sehr interessant zu erfahren, dass es dort einfach eine kaputte Stelle gab.

• Ich frage mich, wie sich jj run von jj fix unterscheidet.
  Auch im Beispiel im Changelog wurde mit jj run cargo fix ausgeführt; die beiden scheinen sich definitiv zu überschneiden.

  • jj run erstellt eine vollständige Working Copy und führt darin den Befehl aus.
    jj fix pipet den Inhalt einer einzelnen Datei an den Befehl und verwendet dessen Ausgabe als neuen Inhalt dieser Datei.
    Wenn ein Tool gut zu jj fix passt, typischerweise wie ein Formatter oder Linter, ist es deutlich schneller; jj run ist aber flexibler.
  • Soweit ich es verstehe, führt run für jede Änderung einen Befehl aus, während fix einen Filter über jede geänderte Datei laufen lässt.
    In meinem Fall würde ich mit run die Testsuite ausführen, um zu prüfen, ob jeder Commit gültig ist, und danach mit fix einen Formatter über die Dateien laufen lassen.
    Aktualisiert habe ich noch nicht; das ist nur meine Interpretation.

• Ich werde jj run ein wenig ausprobieren, gehe aber davon aus, dass es wegen der Art, wie ich direnv nutze, wahrscheinlich komplizierter wird als nötig.