jj v0.42.0 veröffentlicht – Git-kompatibles Versionsverwaltungssystem

• Wechsel zum mimalloc-Speicher-Allocator zur Verbesserung der Multithreading-Performance
• Entfernung der veralteten Befehlsoptionen jj commit --reset-author/--author, jj describe --no-edit/--edit/--reset-author/--author usw.
• Entfernung der Optionen jj git push --allow-new und jj metaedit --update-committer-timestamp
• Entfernung der veralteten Konfigurationsoptionen wie git.auto-local-bookmark und git.push-new-bookmarks
• jj evolog unterstützt keine Legacy-Commit-Predecessors mehr, die vor jj 0.30 aufgezeichnet wurden
• Die Shell-Autovervollständigung zeigt Beschreibungen für benutzerdefinierte alias, revset-alias, template-alias und fileset-alias an und extrahiert Beschreibungen aus dem Feld .doc tabellarischer alias-Definitionen
• jj show akzeptiert mehrere Revisionen und zeigt jede Revision der Reihe nach an, näher an git show
• jj git fetch erzeugt eine auf Change-ID basierende evolution history und rebased lokale Descendant-Revisionen auf neu geschriebene Eltern, wenn das Remote Change-IDs beibehält
• Der Befehl jj util backend name gibt den Namen des Commit-Backends aus, das im aktuellen Repository verwendet wird
• Hinzugefügte Einstellung edit-invocation-mode für den Diff-Editor: Wenn "file-by-file" angegeben ist, wird der Editor einmal pro geänderter Datei ausgeführt, sodass dateibasierte Tools wie vimdiff genutzt werden können
• jj git remote add meldet nun bei leeren Remote-Namen oder Remote-Namen mit Leerzeichen einen Fehler statt eines Panic
• Bei deaktivierter Farbausgabe zeigt der color-words-Diff before/after in getrennten Zeilen an, was die Lesbarkeit von gepipten oder umgeleiteten Diffs verbessert

[GN⁺]

Lobste.rs-Kommentare

• Ich frage mich, ob jj git fetch, wenn es jetzt eine Change-ID-basierte Entwicklungshistorie erzeugt, bedeutet, dass man nicht mehr jedes Mal direkt nach jj git fetch jj new main ausführen muss, sofern das Remote die Change-ID beibehält
  Das wäre dann eine ziemlich gute Verbesserung der Lebensqualität

  • So lese ich das nicht. Beim Fetch entstehen auf main ja weiterhin andere Changes als zuvor, daher dürfte das dabei nicht helfen
  • Wenn man dem Commit-Text einen Trailer hinzufügt, behält jedes Remote den bei
    Ich weiß nur nicht, wie das bei von GitHub erzeugten Merge-Commits ohne Change-ID aussieht

• Mich interessiert eher der Teil, dass durch den Wechsel auf den Speicher-Allocator mimalloc die Multithread-Performance verbessert wurde
  Bei lang laufenden Prozessen habe ich schon Dinge wie jemalloc ausprobiert, um Fragmentierung zu verringern, aber jj fühlt sich eher so an, als starte es in 1 ms und sei in unter 10 ms wieder fertig, daher überrascht es mich, dass ein Allocator-Wechsel spürbar sein soll
  Ich habe noch etwas weiter gesucht und nur gefunden, dass der PR https://github.com/jj-vcs/jj/pull/9484 ist und ungefähr https://github.com/jj-vcs/jj/issues/2490#issuecomment-2595323515; das wirkt nicht wie ein großer Geschwindigkeitssprung. Wenn es aber trotzdem schneller ist und die Änderung nur ein paar Zeilen umfasst, ist das schon okay

• Da stand „wenn das Remote die Change-ID beibehält“, aber ich weiß nicht, ob Remotes das normalerweise tun
  Ich weiß, dass jj gerrit upload einen Change-ID-Footer hinzufügt, aber ein normales jj git push tut das nicht

  • Solange der Commit nicht neu geschrieben wird, kann man wohl davon ausgehen, dass sie erhalten bleibt
    Vorgänge, die Commits umschreiben, wie Squash Merge oder Rebase-Merge bei GitHub, erhalten sie allerdings nicht. Wenn es mit Standard-Tools auf libgit2-Basis verarbeitet wird, bleiben Custom-Header nicht erhalten, und manche Tools wie die Rust-Bibliothek, die GitButler nutzt, unterstützen das Beibehalten von Custom-Headern, aber ich bezweifle, dass Forge-Plattformen so etwas verwenden
  • Ich frage mich, welche Remotes die Change-ID beibehalten
    Ich weiß auch nicht, wie man überprüfen soll, ob sie wirklich korrekt erhalten bleibt
  • Mit Change-ID ist hier offenbar nicht die Gerrit-Change-ID gemeint, sondern die jujutsu-Change-ID
    In der Dokumentation gibt es mehr Details
  • GitLab behält sie bei. Wir nutzen das gerade in der Firma so
    GitHub behält sie ebenfalls bei; das kann man an den pushcx-Commits im lobsters-Codebestand oder an meinen Commits sehen

• Ich frage mich, ob es empfehlenswerte Texte oder Videos dazu gibt, warum man jj statt Standard-Git verwenden sollte
  Ich weiß, dass jj auf Git aufsetzen kann, und habe es auch schon in Hobbyprojekten ausprobiert, aber ich habe bisher noch nicht den entscheidenden Reiz gefunden, warum es besser oder einfacher sein soll