Git 2.39 Version der Quellcodeverwaltung

Nach zweimonatiger Entwicklungszeit wurde das verteilte Versionsverwaltungssystem Git 2.39 veröffentlicht. Git ist eines der beliebtesten, zuverlässigsten und leistungsstärksten Versionskontrollsysteme und bietet flexible nichtlineare Entwicklungstools basierend auf Verzweigung und Zusammenführung. Um die Integrität des Verlaufs und die Widerstandsfähigkeit gegen rückwirkende Änderungen sicherzustellen, wird implizites Hashing des gesamten vorherigen Verlaufs in jedem Commit verwendet. Darüber hinaus ist es möglich, einzelne Tags und Commits mit digitalen Signaturen von Entwicklern zu zertifizieren.

Im Vergleich zur Vorgängerversion enthielt die neue Version 483 Änderungen, die unter Beteiligung von 86 Entwicklern erstellt wurden, von denen 31 erstmals an der Entwicklung beteiligt waren. Wichtigste Neuerungen:

• Der Befehl „git shortlog“, der dazu dient, Zusammenfassungen mit Statistiken aus dem Änderungsverlauf anzuzeigen, hat eine „-group“-Option für die willkürliche Gruppierung von Commits nach Feldern hinzugefügt, die nicht auf Autor oder Committer beschränkt sind. Um beispielsweise eine Liste von Entwicklern mit Informationen über die Anzahl der Änderungen anzuzeigen, unter Berücksichtigung der im Feld „Co-authored-by“ genannten Helfer, könnten Sie den Befehl verwenden: git shortlog -ns --group=author - -group=trailer:co-authored-by

  Die Shortlog-Ausgabe kann mithilfe von Formatierungsspezifizierern aggregiert werden, und die Option „--group“ kann die Erstellung komplexer Berichte erheblich vereinfachen und zusätzliche Sortierbefehle überflüssig machen. Um beispielsweise einen Bericht mit Informationen darüber zu erstellen, wie viele Commits für eine bestimmte Veröffentlichung in jedem Monat akzeptiert wurden, können Sie Folgendes angeben: git shortlog v2.38.0.. —date='format:%Y-%m' —group=' %cd' -s 2 2022-08 47 2022-09 405 2022-10 194 2022-11 5 2022-12 Bisher war es zum Ausführen eines ähnlichen Vorgangs erforderlich, die Dienstprogramme sort und uniq zu verwenden: git log v2.38.0 .. —date='format:%Y -%m' —format='%cd' | sortieren | uniq -c

• Die Funktionen des „Cruft Packs“-Mechanismus, der zum Packen nicht erreichbarer Objekte entwickelt wurde, auf die im Repository nicht verwiesen wird (nicht durch Zweige oder Tags referenziert), wurden erweitert. Nicht erreichbare Objekte werden vom Garbage Collector gelöscht, verbleiben jedoch eine bestimmte Zeit im Repository, bevor sie gelöscht werden, um Race Conditions zu vermeiden. Mit dem „Cruft Packs“-Mechanismus können Sie alle nicht erreichbaren Objekte in einer Packdatei speichern und Daten zur Änderungszeit jedes Objekts in einer separaten Tabelle anzeigen, die in einer separaten Datei mit der Erweiterung „.mtimes“ gespeichert ist, sodass dies der Fall ist nicht mit der gesamten Änderungszeit überschneiden.

  Die Zeitspanne, die nicht erreichbare Objekte im Repository verbleiben, bevor sie tatsächlich gelöscht werden, wird durch die Option „—prune=“ bestimmt " Obwohl das Verzögern vor dem Löschen eine ziemlich effektive und praktische Möglichkeit ist, zu verhindern, dass Race Conditions das Repository beschädigen, ist es nicht 100 % zuverlässig. Um die Wiederherstellung eines beschädigten Repositorys zu erleichtern, bietet die neue Version die Möglichkeit, fehlende Objekte zu speichern, indem die Option „--expire-to“ zum Befehl „git repack“ hinzugefügt wird, mit der Sie eine Datei zum Erstellen eines externen Repositorys angeben können Kopie aller gelöschten Objekte. Um beispielsweise nicht erreichbare Objekte, die sich in den letzten 5 Minuten nicht geändert haben, in der Datei „backup.git“ zu speichern, können Sie den Befehl verwenden: git repack --cruft --cruft-expiration=5.minutes.ago -d --expire -to=../backup.git

• Die Geschwindigkeit des Vorgangs „git grep -cached“ bei der Suche in Bereichen, die teilweises Klonen verwenden (Sparse-Checkout) und für die es Teilindizes gibt (Sparse-Index), wurde erheblich erhöht (bis zu 70 %). Bisher wurde bei Angabe der Option „-cached“ die Suche zunächst im regulären Index und dann in den Teilindizes durchgeführt, was bei der Suche in großen Repositories zu spürbaren Verzögerungen führte.
• Die Überprüfung der Kohärenz neuer Objekte durch den Server, bevor sie während des „Git Push“-Vorgangs im Repository abgelegt werden, wurde beschleunigt. Durch die Umstellung auf die Berücksichtigung nur deklarierter Links bei der Prüfung in einem Test-Repository mit 7 Millionen Links, von denen nur 3 % durch den Push-Vorgang abgedeckt werden, ermöglichten die vorgenommenen Optimierungen eine Reduzierung der Prüfzeit um das 4.5-fache.
• Zum Schutz vor möglichen Integer-Überläufen im Code begrenzt der Befehl „git apply“ die maximale Größe der Patches, die verarbeitet werden können. Wenn die Patchgröße 1 GB überschreitet, wird nun ein Fehler angezeigt.
• Zum Schutz vor potenziellen Schwachstellen wurden Änderungen vorgenommen, um unnötige Informationen aus den gesetzten Headern zu bereinigen, wenn das h2h3-Modul mit der Option GIT_TRACE_CURL=1 oder GIT_CURL_VERBOSE=1 zusammen mit HTTP/2 verwendet wird.
• Beim Auschecken eines Zweigs, der ein symbolischer Link zu einem anderen Zweig ist, zeigt der Befehl „git symbolic-ref HEAD“ jetzt den Namen des Zielzweigs und nicht den Namen des symbolischen Links an.
• Unterstützung für das @{-1}-Argument zur Option „--edit-description“ („git branch —edit-description @{-1}“) hinzugefügt, um die Beschreibung eines vorherigen Zweigs zu bearbeiten.
• Befehl „git merge-tree --stdin“ hinzugefügt, um eine Liste von Optionen über die Standardeingabe zu übergeben.
• Auf Netzwerkdateisystemen ist der fsmonitor-Handler, der Änderungen im Dateisystem überwacht, standardmäßig deaktiviert.

Source: opennet.ru