Veröffentlichung des Quellcode-Management-Systems Git 2.51

Nach zwei Monaten der Entwicklung wird die Version 2.51 des verteilten Systems zur Verwaltung von Quelltexten Git vorgestellt. Git zeichnet sich durch hohe Leistungsfähigkeit aus und bietet Mittel zur nichtlinearen Entwicklung, die auf Verzweigung und Zusammenführung von Zweigen basieren. Um die Integrität der Historie und die Robustheit gegenüber nachträglichen Änderungen zu gewährleisten, werden das implizite Hashing der gesamten vorherigen Historie in jedem Commit sowie die digitale Signatur der Entwickler für einzelne Tags und Commits verwendet. Der Quellcode von Git wird unter der GPLv2+-Lizenz verteilt.

Im Vergleich zur vorherigen Version wurden 506 Änderungen in die neue Version aufgenommen, die mit Beteiligung von 91 Entwicklern erstellt wurden (21 davon haben zum ersten Mal an der Entwicklung von Git teilgenommen). Die wichtigsten Neuerungen (1, 2, 3):

• Die Leistung der Befehle "git push" und "git fetch" in Repositories mit einer großen Anzahl an Referenzen wurde verbessert. Diese Beschleunigung resultiert aus der Aktualisierung von Referenzen im Batch-Modus, bei dem mehrere Referenzen in einer Transaktion verarbeitet werden, anstatt für jede Referenz eine separate Transaktion zu erstellen. Diese Optimierung hat die Geschwindigkeit des "reftable"-Backends erheblich gesteigert, welches nun das "files"-Backend übertrifft. Beispielsweise wurde im Test-Repository mit 10.000 Referenzen die Leistung von "git fetch" beim Einsatz des "reftable"-Backends um das 22-Fache gesteigert, während es beim "files"-Backend nur um das 1,25-Fache zunahm. Für "git push" betrug der Zuwachs 18 und 1,21 mal, jeweils.
• Eine neue Methode zum Verpacken in Pack-Dateien für Teile des Repositories wurde vorgeschlagen, die nicht mit unerreichbaren Objekten verknüpft sind, auf die im Repository keine Links bestehen (weder von Branches noch von Tags). Informationen über unerreichbare Objekte werden in separaten Pack-Dateien („cruft packs“) gespeichert, was eine Abbildung in mehrpack-indizes (MIDX, multi-pack index) erforderte, um Objekte zu erfassen, die ursprünglich unerreichbar waren und nur im Cruft-Paket gespeichert wurden, aber nach einem auf sie verweisenden Commit erreichbar wurden.

  In der neuen Version wird beim Repacking von Pack-Dateien sichergestellt, dass zusätzliche Kopien der erreichbaren Objekte, die nur in Cruft-Dateien gespeichert sind, erhalten bleiben. Diese Änderung gewährleistet, dass der Satz von Pack-Dateien, der für die Speicherung der erreichbaren Objekte verwendet wird, keine Objekte enthält, die auf andere Objekte verweisen, die außerhalb dieses Satzes gespeichert sind. Um unerreichbare Inhalte von Cruft-Dateien aus den multipack-Index (MIDX) zu entfernen, wurde die Einstellung „repack.MIDXMustContainCruft“ vorgeschlagen, die es ermöglicht, die Größe solcher Indizes erheblich zu reduzieren. Die Aktivierung dieser Einstellung im GitHub-Repository führte zu einer Reduktion der Größe der MIDX-Indizes um 38 %, zu einer Beschleunigung des Schreibens in die MIDX-Indizes um 35 % und zu einer Verbesserung der Leseleistung um 5 %.
• Der Befehl „git pack-objects“ wurde um die Option „—path-walk“ erweitert, die eine neue Methode zur Informationsbeschaffung über Objekte beim Wiederpacken von Pack-Dateien einführt. Anstatt die Objekte in Reihenfolge der Revisionen zu durchlaufen, werden im Modus „—path-walk“ die Objekte durch das Durchlaufen von File-Pfaden aufgezählt, was es ermöglicht, alle Objekte mit demselben File-Pfad gleichzeitig zu packen. Dieser Ansatz erlaubt es, die Heuristik, die Hashing verwendet, um die Beziehung des Objekts zu seinem File-Pfad zu bestimmen, auszuschließen und die Objekte vor dem Packen nicht sortieren zu müssen. Im Modus „—path-walk“ ist die Größe der generierten Pack-Dateien deutlich geringer als bei der Gruppierung von Objekten durch Hashes.
• Das Format für den Austausch von gespeicherten Zuständen des Arbeitsverzeichnisses und von Indizes im Repository, die mit dem Befehl «git stash» erstellt werden, ist definiert. Das neue Format ermöglicht es, gespeicherte Änderungen (stash-Einträge) als eine Sequenz von Commits zu kodieren. Für den Import und Export stehen die Unterbefehle «git stash import» und «git stash export» zur Verfügung, mit denen gespeicherte Zustände von einem System auf ein anderes übertragen und Push- oder Pull-Operationen mit diesen Zuständen wie mit normalen Branches oder Tags durchgeführt werden können. git stash export —to-ref refs/stashes/my-stash git push origin refs/stashes/my-stash … git fetch origin ‘+refs/stashes/*:refs/stashes/*’ git stash import refs/stashes/my-stash
• Im Befehl «git cat-file», der den Inhalt bestimmter Objekte anzeigt, wurde bei der Verwendung der Optionen «—batch» und «—batch-check» die Möglichkeit implementiert, Informationen über fehlende Objekte (zum Beispiel aufgrund einer Beschädigung des Repositories) und Submodule anzuzeigen. Zuvor gab die Angabe eines Pfades zu einem Submodul im Befehl «git cat-file —batch-check» «missing» aus, jetzt wird die Objekt-ID angezeigt.
• Im Befehl „git log“ wurden Optimierungen basierend auf Bloom-Filtern implementiert, um die Suche in der Änderungsvergangenheit zu beschleunigen, wenn mehrere Dateipfade angegeben werden, z. B. „git log — path/to/a path/to/b.“
• Die Befehle „git switch“ und „git restore“ wurden stabilisiert, die seit 2019 als experimentell betrachtet wurden. Diese Befehle werden als moderne Äquivalente zu „git checkout“ präsentiert und trennen solche wenig miteinander verbundenen Funktionen wie das Verwalten von Branches (Wechseln und Erstellen) und das Wiederherstellen von Dateien im Arbeitsverzeichnis.
• Der Befehl „git whatchanged“, der äquivalent zu „git log —raw“ ist, wurde als veraltet erklärt und soll in der Git-Version 3.0 entfernt werden.
• Im Befehl „git for-each-ref“ wurde die Option „—start-after“ hinzugefügt, die zusammen mit der Option „—count“ verwendet werden kann, um eine paginierte Ausgabe zu organisieren.
• Den Befehlen „git merge“ und „git pull“ wurde die Option „—compact-summary“ hinzugefügt, um ein kompaktes Format der Zusammenfassungsinformationen über Änderungen anstelle des diffstat-Formats zu verwenden.
• In der Git-Codebasis ist die Verwendung des Schlüsselworts „bool“, das im C99-Standard eingeführt wurde, erlaubt. Auch einige Funktionen von C99, die experimentell in Git genutzt werden, sind dokumentiert (zum Beispiel wird geplant, Mitte 2026 die Verwendung von Konstruktionen wie „(struct foo){ .member = value };“ zuzulassen). Ein Compiler, der C99 unterstützt, ist seit 2021 für Git erforderlich, doch die Funktionen der C99-Spezifikation werden sehr vorsichtig implementiert, um die Kompatibilität mit Compilern, die diesen Standard nur teilweise unterstützen, zu wahren.
• Die Regeln zur Abnahme von Patches wurden geändert, um das Einreichen von Patches unter einem Pseudonym zu erlauben, nicht nur unter dem echten Namen des Entwicklers. Diese Änderung entspricht den Patchannahmeregeln für den Linux-Kernel.
• Die Liste der inkompatiblen Änderungen wurde aktualisiert, die in der Git-Version 3.0 angewendet werden. Zu den bedeutenden Änderungen in der bevorstehenden Veröffentlichung von Git 3.0 gehört der standardmäßige Wechsel zu objektbasierten Identifikatoren, die auf dem SHA-256 Hashalgorithmus basieren, bei der Initialisierung neuer Repositories sowie die Verwendung des 'reftable'-Formats zur Speicherung von Verweisen auf Branches und Tags im Repository (unter Verwendung von blockbasierter Speicherung aus dem JGit-Projekt, optimiert für die Speicherung einer sehr großen Anzahl von Verweisen).

Quelle: opennet.ru