Veröffentlichung des Versionskontrollsystems Git 2.39

Nach zwei Monaten Entwicklung wurde die Version 2.39 des verteilten Systems zur Verwaltung von Quelltexten Git veröffentlicht. Git gehört zu den beliebtesten, zuverlässigsten und leistungsfähigsten Versionsverwaltungssystemen und bietet flexible Möglichkeiten für nichtlineare Entwicklungen, die auf Branching und Merging basieren. Um die Integrität der Historie zu gewährleisten und Änderungen "rückwirkend" zu verhindern, wird die gesamte vorherige Historie in jedem Commit implizit gehasht; zudem ist die Bestätigung durch digitale Signaturen der Entwickler für einzelne Tags und Commits möglich.

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

• Das Kommando „git shortlog“, das zur Anzeige von Zusammenfassungen mit Statistiken aus der Änderungshistorie dient, wurde um die Option „—group“ erweitert, um die Gruppierung von Commits nach beliebigen Feldern zu ermöglichen, die nicht auf den Autor oder Commiter beschränkt sind. Um beispielsweise eine Liste der Entwickler anzuzeigen, die Informationen über die Anzahl der Änderungen enthält und Co-Autoren berücksichtigt, die im Feld „Co-authored-by“ erwähnt werden, kann der Befehl verwendet werden: git shortlog -ns —group=author —group=trailer:co-authored-by

  Die Ausgabe des shortlogs kann mithilfe von Format-Spezifizierern aggregiert werden, und die Option „—group“ erleichtert erheblich die Erstellung komplexer Berichte, wodurch zusätzliche Sortierbefehle vermieden werden. Um beispielsweise einen Bericht darüber zu erstellen, wie viele Commits für eine bestimmte Version in jedem Monat akzeptiert wurden, können Sie 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 für einen ähnlichen Vorgang die Nutzung der Tools sort und uniq erforderlich gewesen: git log v2.38.0.. —date=’format:%Y-%m’ —format=’’ | sort | uniq -c
• Die Funktionen des Mechanismus „cruft packs“ wurden erweitert, um unerreichbare Objekte, auf die im Repository keine Verweise existieren (weder durch Branches noch durch Tags), zu verpacken. Unerreichbare Objekte werden vom Garbage Collector entfernt, bleiben jedoch zunächst eine gewisse Zeit im Repository, um Rennbedingungen auszuschließen. Der „cruft packs“-Mechanismus ermöglicht die Speicherung aller unerreichbaren Objekte in einer einzigen Pack-Datei, während die Änderungszeit jedes Objekts in einer separaten Tabelle festgehalten wird, die in einer eigenen Datei mit der Erweiterung „.mtimes“ gespeichert wird, um eine Überschneidung mit der allgemeinen Änderungszeit zu vermeiden.

  Die Zeitspanne, in der unerreichbare Objekte im Repository verbleiben, bevor sie tatsächlich gelöscht werden, wird durch die Option „—prune=“ definiert. Obwohl die Verzögerung vor der Löschung eine recht effektive und praktische Methode ist, um Repository-Schäden durch Wettlaufbedingungen zu verhindern, ist sie nicht zu 100 % zuverlässig. Um die Wiederherstellung eines beschädigten Repositories zu erleichtern, bietet die neue Version die Möglichkeit, fehlende Objekte zu speichern. Dafür wurde der Befehl „git repack“ um die Option „—expire-to“ erweitert, die es ermöglicht, eine Datei anzugeben, um eine externe Kopie aller zu löschenden Objekte zu erstellen. Zum Beispiel kann man zur Speicherung von unerreichbaren Objekten, die sich in den letzten 5 Minuten nicht geändert haben, folgenden Befehl verwenden: git repack —cruft —cruft-expiration=5.minutes.ago -d —expire-to=../backup.git

• Die Geschwindigkeit der Ausführung des Befehls „git grep —cached“ wurde erheblich erhöht (um bis zu 70 %) bei Suchen in Bereichen, in denen partielles Klonen (sparse-checkout) angewendet wird und für die partielle Indizes (sparse index) existieren. Zuvor wurde bei Angabe der Option „—cached“ zuerst im regulären Index und danach in den partiellen Indizes gesucht, was zu spürbaren Verzögerungen bei Suchen in großen Repositorien führte.
• Die Ausführung wurde beschleunigt um Server die Überprüfung der Konsistenz neuer Objekte, bevor sie in das Repositorium eingefügt werden, bei Ausführung des Befehls „git push“. Durch die Umstellung auf die Überprüfung nur der deklarierten Referenzen konnten in einem Test-Repositorium mit 7 Millionen Referenzen, von denen nur 3 % durch den Push-Befehl erfasst werden, die Optimierungen die Überprüfungszeit um das 4,5-fache verkürzen.
• Um vor potenziellen ganzzahligen Überläufen im Code zu schützen, wurde die maximale Größe der verarbeiteten Patches im Befehl „git apply“ begrenzt. Wenn die Patch-Größe 1 GB überschreitet, wird jetzt ein Fehler ausgegeben.
• Um potenzielle Sicherheitsanfälligkeiten zu vermeiden, wurden Änderungen vorgenommen, um überflüssige Informationen aus den Kopfzeilen zu entfernen, die beim Einsatz des Moduls h2h3 mit den Optionen GIT_TRACE_CURL=1 oder GIT_CURL_VERBOSE=1 zusammen mit HTTP/2 ausgegeben werden.
• Bei der Ausführung des Check-Out-Befehls mit einem Branch, der ein symbolischer Verweis auf einen anderen Branch ist, gibt der Befehl „git symbolic-ref HEAD“ jetzt den Namen des Ziel-Branches und nicht den Namen des symbolischen Verweises aus.
• Die Unterstützung des Arguments @{-1} in der Option „—edit-description“ („git branch —edit-description @{-1}“) wurde hinzugefügt, um die Beschreibung des vorherigen Branches zu bearbeiten.
• Der Befehl „git merge-tree —stdin“ wurde hinzugefügt, der es ermöglicht, eine Liste von Parametern über den Standard-Eingabestrom zu übergeben.
• Bei Netzwerkdateisystemen ist der fsmonitor, der Änderungen im Dateisystem überwacht, standardmäßig deaktiviert.

Quelle: opennet.ru