Veröffentlichung des Versionsverwaltungssystems Git 2.51

Nach zwei Monaten Entwicklung wurde die Version 2.51 des verteilten Systems zur Verwaltung von Quelltexten Git veröffentlicht. Git zeichnet sich durch hohe Leistung aus und bietet Mittel für nicht-lineare Entwicklung, die auf Verzweigung und Zusammenführung von Branches basieren. Um die Integrität der Historie und die Resistenz gegen nachträgliche Änderungen sicherzustellen, wird eine implizite Hash-Funktion auf die gesamte vorherige Historie in jedem Commit angewendet, sowie die Zertifizierung von einzelnen Tags und Commits durch digitale Signaturen der Entwickler. Der Git-Code wird unter der GPLv2+-Lizenz verbreitet.

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

• Die Leistung der Befehle «git push» und «git fetch» in Repositories mit einer großen Anzahl von Referenzen wurde verbessert. Die Beschleunigung wurde durch das Aktualisieren von Referenzen im Batch-Modus erreicht, bei dem in einer Transaktion mehrere Referenzen gleichzeitig verarbeitet werden, anstatt für jede Referenz eine separate Transaktion zum Aktualisieren zu erstellen. Diese Optimierung hat die Geschwindigkeit des «reftable»-Backends deutlich erhöht, welches jetzt das «files»-Backend in der Leistung übertrifft. Beispielsweise stieg die Leistung von «git fetch» bei Verwendung des «reftable»-Backends in einem Test-Repository mit 10.000 Referenzen um das 22-Fache, während sie beim «files»-Backend um das 1,25-Fache zunahm. Für «git push» betrug die Steigerung 18 und 1,21-fach, jeweils.
• Eine neue Methode zur Verpackung von Teilen des Repositories in Packdateien wurde vorgeschlagen, die nicht mit der Verfolgung unerreichbarer Objekte verbunden sind, auf die im Repository keine Referenzen existieren (keine Branches oder Tags verweisen darauf). Informationen über unerreichbare Objekte werden in separaten Packdateien (»cruft packs«) gespeichert, was die Notwendigkeit mit sich brachte, sie in mehrpackindizes MIDX (multi-pack index) widerzuspiegeln, um Objekte abzudecken, die ursprünglich unerreichbar waren und nur im cruft-Pack gespeichert wurden, aber nach einem Commit, das sich auf sie bezieht, erreichbar wurden.

  In der neuen Version wurde beim Repacken von Packdateien sichergestellt, dass zusätzliche Kopien erreichbarer Objekte, die nur in Cruft-Dateien gespeichert sind, erhalten bleiben. Diese Änderung gewährleistet, dass im Satz der Packdateien, die zur Speicherung erreichbarer Objekte verwendet werden, keine Objekte enthalten sind, die auf andere Objekte verweisen, die außerhalb dieses Satzes gespeichert sind. Um unerreichbare Inhalte von Cruft-Dateien aus den multiplen Pack-Indizes (MIDX) auszuschließen, wurde die Einstellung "repack.MIDXMustContainCruft" vorgeschlagen, die es ermöglicht, die Größe solcher Indizes deutlich zu reduzieren. Die Aktivierung dieser Einstellung in einem GitHub-Repository hat die Größe der MIDX-Indizes um 38 % verringert, die Schreibgeschwindigkeit in die MIDX-Indizes um 35 % erhöht und die Lesegeschwindigkeit um 5 % gesteigert.
• Dem Befehl „git pack-objects“ wurde die Option „—path-walk“ hinzugefügt, die eine neue Methode zur Informationssammlung über Objekte beim Repacken von Packdateien umfasst. Anstelle der Durchsuchung von Objekten in der Reihenfolge der Revisionen werden im Modus „—path-walk“ Objekte durch das Durchlaufen von Dateipfaden aufgelistet, was es ermöglicht, alle Objekte mit demselben Dateipfad gleichzeitig zu verpacken. Dieser Ansatz eliminiert die Heuristik, die Hashing verwendet, um die Beziehung eines Objekts zu seinem Dateipfad festzustellen, und ermöglicht es, die Objekte vor dem Verpacken nicht sortieren zu müssen. Bei der Verwendung des Modus „—path-walk“ ist die Größe der generierten Packdateien erheblich kleiner als bei der Gruppierung von Objekten mithilfe von Hashes.
• Ein Format für den Austausch von gespeicherten Zuständen des Arbeitsbaums und der Indizes im Repository, die mit dem Befehl „git stash“ erstellt wurden, wurde definiert. Das neue Format ermöglicht es, die gespeicherten Änderungen (stash-Einträge) als eine Sequenz von Commits zu kodieren. Für den Import und Export wurden die Unterbefehle „git stash import“ und „git stash export“ vorgeschlagen, die verwendet werden können, um gespeicherte Zustände von einem System auf ein anderes zu übertragen und Push- oder Pull-Operationen mit diesen Zuständen wie mit normalen Branches oder Tags durchzuführen. 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 gegebener Objekte ausgibt, wurde die Möglichkeit implementiert, Informationen über fehlende Objekte (zum Beispiel aufgrund von Repository-Beschädigungen) und Submodule anzuzeigen, wenn die Optionen „—batch“ und „—batch-check“ verwendet werden. Früher gab der Befehl „git cat-file —batch-check“ bei Angabe des Pfades zu einem Submodul „missing“ aus, jetzt wird die Objekt-ID angezeigt.
• Im Befehl „git log“ werden Optimierungen auf Grundlage von Bloom-Filtern eingesetzt, um die Suche in der Historie von Änderungen zu beschleunigen, wenn Filter mit mehreren Dateipfaden angegeben werden, zum Beispiel „git log — path/to/a path/to/b“.
• Die Befehle „git switch“ und „git restore“ wurden stabilisiert, die seit 2019 als experimentell betrachtet wurden. Die Befehle werden als moderne Äquivalente zu „git checkout“ präsentiert, die so unterschiedliche Funktionen dieser Befehle wie das Verwalten von Branches (Wechseln und Erstellen) und das Wiederherstellen von Dateien im Arbeitsverzeichnis voneinander trennen.
• Der Befehl „git whatchanged“, der äquivalent zu „git log —raw“ ist, wurde als veraltet erklärt und ist zur Entfernung in der Git-Version 3.0 vorgesehen.
• Im Befehl „git for-each-ref“ wurde die Option „—start-after“ hinzugefügt, die zusammen mit der Option „—count“ für eine paginierte Ausgabe verwendet werden kann.
• Im Befehl „git merge“ und „git pull“ wurde die Option „—compact-summary“ hinzugefügt, um ein kompaktes Format für die Zusammenfassung von Ä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. Einige in Git experimentell verwendete C99-Funktionen sind ebenfalls dokumentiert (zum Beispiel wird geplant, Mitte 2026 die Verwendung von Konstruktionen „(struct foo){ .member = value };“ zuzulassen). Ein C99-kompatibler Compiler wird seit 2021 für Git vorausgesetzt, doch die Funktionen der C99-Spezifikation werden sehr vorsichtig umgesetzt, um die Kompatibilität mit Compilern zu wahren, die nur teilweise diesen Standard unterstützen.
• Die Regeln für die Annahme von Patches wurden geändert, um die Einreichung von Patches unter einem Pseudonym zuzulassen, nicht nur unter dem echten Namen des Entwicklers. Diese Änderung entspricht den Regeln für die Annahme von Patches im Linux-Kernel.
• Die Liste der inkompatiblen Änderungen wurde aktualisiert, die in der Git-Version 3.0 angewendet werden. Zu den wesentlichen Änderungen in der bevorstehenden Version Git 3.0 gehört die standardmäßige Umstellung auf Objekt-IDs basierend auf dem SHA-256-Hashalgorithmus bei der Initialisierung neuer Repositories sowie die Verwendung des Formats „reftable“ zur Speicherung von Verweisen auf Branches und Tags im Repository (unter Verwendung des Blockspeichers des JGit-Projekts, der für die Speicherung einer sehr großen Anzahl von Verweisen optimiert wurde).

Quelle: opennet.ru