Veröffentlichung des Versionskontrollsystems Git 2.39

Nach zwei Monaten der Entwicklung wurde die Veröffentlichung des verteilten Systems zur Verwaltung von Quelltexten Git 2.39 abgeschlossen. Git ist eines der beliebtesten, zuverlässigsten und leistungsfähigsten Versionskontrollsysteme, das flexible Mittel für die nichtlineare Entwicklung bietet, die auf Branching und Merging basieren. Um die Integrität der Historie und die Widerstandsfähigkeit gegen rückwirkende Änderungen sicherzustellen, wird ein implizites Hashing der gesamten vorherigen Historie in jedem Commit verwendet, außerdem ist es möglich, digitale Signaturen von Entwicklern für einzelne Tags und Commits zu verifizieren.

Im Vergleich zur vorherigen Version wurden in die neue Version 483 Änderungen aufgenommen, die mit Beteiligung von 86 Entwicklern vorbereitet wurden, von denen 31 zum ersten Mal an der Entwicklung teilnahmen. Die wichtigsten Neuerungen:

• In das Kommando „git shortlog“, das für die Anzeige von Zusammenfassungen mit Statistiken aus der Änderungsdauer gedacht ist, wurde die Option „—group“ für eine beliebige Gruppierung von Commits nach Feldern hinzugefügt, die nicht auf Autor oder Committer beschränkt sind. Zum Beispiel kann der Befehl verwendet werden, um eine Liste von Entwicklern mit Informationen über die Anzahl der Änderungen zu zeigen, einschließlich der Mitwirkenden, die im Feld „Co-authored-by“ erwähnt werden: git shortlog -ns —group=author —group=trailer:co-authored-by

  Die Ausgabe von shortlog kann durch Formatierungsspezifizierer aggregiert werden, und die Option „—group“ erleichtert erheblich die Erstellung komplexer Berichte und die Vermeidung zusätzlicher Sortierbefehle. Beispielsweise kann man zur Erstellung eines Berichts darüber, wie viele Commits für einen bestimmten Release in jedem Monat akzeptiert wurden, folgendes angeben: git shortlog v2.38.0.. —date=’format:%Y-%m’ —group=’’ -s 2 2022-08 47 2022-09 405 2022-10 194 2022-11 5 2022-12 Früher hätte man für die Durchführung einer ähnlichen Operation die Tools sort und uniq benötigt: git log v2.38.0.. —date=’format:%Y-%m’ —format=’’ | sort | uniq -c
• Die Möglichkeiten des Mechanismus „cruft packs“ wurden erweitert, der zum Verpacken unerreichbarer Objekte bestimmt ist, auf die im Repository keine Links vorhanden sind (keine Verweisen wie Branches oder Tags). Unerreichbare Objekte werden vom Garbage Collector entfernt, verbleiben jedoch für eine bestimmte Zeit im Repository, um Rennbedingungen zu vermeiden. Der Mechanismus „cruft packs“ ermöglicht das Speichern aller unerreichbaren Objekte in einer einzigen Pack-Datei, während die Daten über die Modifikationszeit jedes Objekts in einer separaten Tabelle, die in einer separaten Datei mit der Erweiterung „.mtimes“ gespeichert wird, reflektiert werden, um Überschneidungen mit der allgemeinen Änderungszeit zu vermeiden.

  Die Zeit, die unerreichbare Objekte im Repository verbleiben, bevor sie tatsächlich gelöscht werden, wird durch die Option „—prune=<date>“ bestimmt. Obwohl die Verzögerung vor der Löschung eine recht effektive und praktische Methode zur Vermeidung von Repository-Beschädigungen aufgrund von Rennbedingungen ist, ist sie nicht zu 100 % zuverlässig. Um die Wiederherstellung eines beschädigten Repositories zu erleichtern, wurde in der neuen Version die Möglichkeit eingeführt, fehlende Objekte zu speichern. Dazu wurde der Befehl „git repack“ um die Option „—expire-to“ erweitert, die es ermöglicht, eine Datei anzugeben, um eine externe Kopie aller gelöschten Objekte zu erstellen. Zum Beispiel kann der Befehl verwendet werden, um unerreichbare Objekte, die sich in den letzten 5 Minuten nicht geändert haben, in der Datei backup.git zu speichern: git repack —cruft —cruft-expiration=5.minutes.ago -d —expire-to=..\/backup.git

• Die Geschwindigkeit der Durchführung der Operation „git grep —cached“ wurde signifikant erhöht (um bis zu 70 %), wenn in Bereichen gesucht wird, in denen partielle Klonungen (sparse-checkout) angewendet werden und für die partielle Indizes (sparse index) existieren. Früher wurde bei Angabe der Option „—cached“ zunächst im normalen Index gesucht, bevor in den partiellen Indizes gesucht wurde, was zu spürbaren Verzögerungen bei der Suche in großen Repositories führte.
• Die Ausführungsgeschwindigkeit wurde beschleunigt bei Server den Überprüfungen der Konsistenz neuer Objekte, bevor sie beim Durchführen der Operation „git push“ in das Repository eingefügt werden. Durch den Wechsel zu einer Überprüfung, die nur die deklarierten Verweise berücksichtigt, konnten in einem Test-Repository mit 7 Millionen Verweisen, von denen nur 3 % durch die Push-Operation erfasst wurden, die vorgenommenen Optimierungen die Überprüfungszeit um das 4,5-Fache reduzieren.
• Zum Schutz vor potenziellen Ganzzahlüberläufen im Code ist in dem Befehl "git apply" die maximale Größe der verarbeiteten Patches begrenzt. Wenn die Größe des Patches 1 GB überschreitet, wird nun eine Fehlermeldung angezeigt.
• Zum Schutz vor potenziellen Sicherheitsanfälligkeiten wurden Änderungen vorgenommen, um überflüssige Informationen aus den Headern zu bereinigen, die beim Einsatz des Moduls h2h3 mit den Optionen GIT_TRACE_CURL=1 oder GIT_CURL_VERBOSE=1 zusammen mit HTTP/2 ausgegeben werden.
• Beim Ausführen des Checkout-Vorgangs mit einem Branch, der ein symbolischer Verweis auf einen anderen Branch ist, gibt der Befehl "git symbolic-ref HEAD" nun den Namen des Zielbranches aus und nicht den Namen des symbolischen Verweises.
• Unterstützung für das Argument @{-1} in der Option "—edit-description" ("git branch —edit-description @{-1}") zum Bearbeiten der Beschreibung des vorherigen Branches wurde hinzugefügt.
• Der Befehl "git merge-tree —stdin" wurde hinzugefügt, der es ermöglicht, eine Liste von Parametern über den Standard-Eingabestrom zu übergeben.
• In Netzwerkdateisystemen ist standardmäßig der fsmonitor-Handler deaktiviert, der Änderungen im Dateisystem verfolgt.

Quelle: opennet.ru