Das System zur Verwaltung von Quelltexten Git 2.41 ist verfügbar

Nach drei Monaten Entwicklung wurde die Veröffentlichung des verteilten Systems zur Verwaltung von Quelltexten Git 2.41 bekannt gegeben. Git ist eines der beliebtesten, zuverlässigsten und leistungsstärksten Versionsverwaltungssysteme, das flexible Mittel für nichtlineare Entwicklungen basierend auf Branching und Merging bereitstellt. Um die Integrität der Historie und die Widerstandsfähigkeit gegenüber rückwirkenden Änderungen zu gewährleisten, wird eine implizite Hash-Wertung der gesamten vorhergehenden Historie in jedem Commit verwendet. Zudem ist es möglich, digitale Signaturen von Entwicklern für einzelne Tags und Commits beizufügen.

Im Vergleich zur vorherigen Version wurden in die neue Version 542 Änderungen übernommen, die von 95 Entwicklern vorbereitet wurden, von denen 29 erstmals an der Entwicklung teilnahmen. Die Hauptneuerungen sind:

• Die Verarbeitung von unerreichbaren Objekten wurde verbessert, auf die im Repository keine Verweise (keine Branches oder Tags) existieren. Unerreichbare Objekte werden vom Garbage Collector gelöscht, verbleiben jedoch eine gewisse Zeit im Repository, um Rennzustände zu vermeiden. Um die Verweildauer unerreichbarer Objekte zu verfolgen, müssen Labels mit Zeitstempeln für diese Objekte zugeordnet werden, was es nicht erlaubt, sie in einer einzigen Pack-Datei zu speichern, in der alle Objekte eine gemeinsame Änderungszeit haben. Früher wurde jedes unerreichbare Objekt in einer separaten Datei gespeichert, was bei zahlreichen frischen unerreichbaren Objekten, die noch nicht gelöscht werden sollten, zu Problemen führte. In der neuen Version wird standardmäßig der Mechanismus „cruft packs“ zum Packen unerreichbarer Objekte verwendet, der es ermöglicht, alle unerreichbaren Objekte in einer einzigen Pack-Datei zu speichern, während die Informationen über die Änderungszeit jedes Objekts in einer separaten Tabelle gespeichert werden, die sich in einer Datei mit der Erweiterung „.mtimes“ befindet und über eine Indexdatei mit der Erweiterung „.idx“ verknüpft ist.
• Standardmäßig ist die Verwendung des Rückwärtsindex (revindex) für Pack-Dateien aktiviert. Bei Tests im Repository torvalds/linux ermöglichte die Anwendung des Rückwärtsindex eine 1,49-fache Beschleunigung ressourcenintensiver „git push“-Operationen sowie eine 77-fache Beschleunigung einfacher Operationen, wie das Berechnen der Größe eines Objekts mittels „git cat-file —batch=’%(objectsize:disk)'“. Dateien („.rev“) mit Rückwärtsindex werden im Repository im Verzeichnis „.git/objects/pack“ gespeichert.

  Erinnern wir uns daran, dass Git alle Daten in Form von Objekten speichert, die in separaten Dateien abgelegt werden. Um die Effizienz der Arbeit mit dem Repository zu erhöhen, werden die Objekte zusätzlich in Pack-Dateien abgelegt, in denen die Informationen in Form eines Stroms von aufeinanderfolgenden Objekten dargestellt werden (ein ähnliches Format wird beim Übertragen von Objekten mit den Befehlen git fetch und git push verwendet). Für jede Pack-Datei wird eine Indexdatei (.idx) erstellt, die es ermöglicht, anhand der Objekt-ID sehr schnell die Offsets in der Pack-Datei zu bestimmen, wo dieses Objekt gespeichert ist.

  Der im neuen Release enthaltene Rückwärtsindex zielt darauf ab, den Prozess der Identifizierung der Objekt-ID anhand der Informationen über die Platzierung des Objekts in der Pack-Datei zu optimieren. Zuvor wurde eine solche Umwandlung während der Analyse der Pack-Datei in Echtzeit durchgeführt und nur im Speicher gehalten, was die Wiederverwendbarkeit solcher Indizes verhinderte und es erforderte, den Index jedes Mal neu zu generieren. Der Vorgang zum Erstellen des Indexes reduziert sich auf den Aufbau eines Arrays von „Objekt-Position“-Paaren und deren Sortierung nach Position, was bei großen Pack-Dateien viel Zeit in Anspruch nehmen kann.

  Zum Beispiel wurde die Ausgabe des Inhalts von Objekten, bei der ein direkter Index verwendet wurde, 62-mal schneller durchgeführt als die Anzeige der Größe von Objekten, für die die Daten zur Beziehung zwischen Position und Objekt nicht indiziert wurden. Nach der Verwendung des Rückwärtsindex benötigten die genannten Operationen etwa die gleiche Zeit. Rückwärtsindizes ermöglichen es auch, die Vorgänge beim Senden von Objekten bei den Befehlen fetch und push durch die direkte Übertragung bereits bereitgestellter Daten von der Festplatte zu beschleunigen.

  
• Im Protokoll „Credential Helper“, das für die Übertragung von Zugangsdaten beim Zugriff auf Repositories mit eingeschränktem Zugriff verwendet wird, wurde die Unterstützung für die Übertragung von WWW-Authenticate-Headern zwischen dem Credential Handler und dem Dienst, wo die Authentifizierung erfolgt, hinzugefügt. Die Unterstützung des WWW-Authenticate-Headers ermöglicht die Übertragung von OAuth-Scoped Parametern für eine granularere Zugriffskontrolle des Benutzers auf die Repositories und die Abgrenzung von Bereichen, die für Anfragen verfügbar sind.
• In den Befehl for-each-ref wurde eine Formatierungsoption „%(ahead-behind:<base>)“ hinzugefügt, die es ermöglicht, auf einmal Informationen über die Anzahl von Commits zu erhalten, die in einem bestimmten Branch vorhanden oder nicht vorhanden sind, im Vergleich zu einem anderen Branch (wie weit einer Branch hinter oder vor einem anderen in Bezug auf die Commits liegt). Zuvor mussten für derartige Informationen zwei separate Befehle ausgeführt werden: „git rev-list —count main..my-feature“ zur Ermittlung der Branch-spezifischen Commits und „git rev-list —count my-feature..main“ zur Ermittlung der fehlenden Commits. Jetzt können derartige Berechnungen auf einen einzigen Befehl reduziert werden, was das Schreiben von Handlern vereinfacht und die Ausführungszeit verkürzt. Zum Beispiel kann für die Anzeige von nicht zusammengeführten Branches und zur Einschätzung der Verzögerung oder Vorlaufzeit im Vergleich zum Hauptbranch eine Einzeiler verwendet werden: $ git for-each-ref —no-merged=origin/HEAD \ —format=’%(refname:short) %(ahead-behind:origin/HEAD)’ \ refs/heads/tb/ | column -t tb/cruft-extra-tips 2 96 tb/for-each-ref—exclude 16 96 tb/roaring-bitmaps 47 3 anstelle des zuvor verwendeten Skripts, das 17-mal langsamer ausgeführt wird: $ git for-each-ref —format=’%(refname:short)’ —no-merged=origin/HEAD \ refs/heads/tb | while read ref do ahead=„$(git rev-list —count origin/HEAD..$ref)“ behind=„$(git rev-list —count $ref..origin/HEAD)“ printf „%s %d %d\n“ „$ref“ „$ahead“ „$behind“ done | column -t tb/cruft-extra-tips 2 96 tb/for-each-ref—exclude 16 96 tb/roaring-bitmaps 47 3
• In den Befehl „git fetch“ wurde die Option „—porcelain“ hinzugefügt, bei deren Angabe die Ausgabe im Format „<flag> <old-object-id> <new-object-id> <local-reference>“ erstellt wird, das weniger lesbar, aber besser für die Verarbeitung in Skripten geeignet ist.
• Eine Einstellung „fetch.hideRefs“ wurde hinzugefügt, die die „git fetch“-Operationen beschleunigt, indem sie einen Teil der Links im lokalen Repository während der Überprüfung auf den vollständigen Satz von Objekten auf Serverseite verbirgt, was Zeit spart, indem die Überprüfung eingeschränkt wird. Server, von denen Daten direkt abgerufen werden. Zum Beispiel hat bei einem Test auf einem System mit Repositories, die eine große Anzahl an verfolgten externen Links enthalten, das Ausschließen aller Links außer den an das Ziel adressierten zu einem Server $remote, die Ausführungszeit des Befehls „git fetch“ von 20 Minuten auf 30 Sekunden verkürzt. $ git -c fetch.hideRefs=refs -c fetch.hideRefs=!refs/remotes/$remote \ fetch $remote
• Im Befehl „git fsck“ wurde die Möglichkeit implementiert, Beschädigungen, die Übereinstimmung von Prüfziffern und die Korrektheit der Werte in den Verfügbarkeits-Bitkarten und Rückwärtsindizes zu überprüfen.
• Im Befehl „git clone —local“ wurde eine Fehlermeldung implementiert, die beim Versuch, aus einem Repository mit symbolischen Links innerhalb von $GIT_DIR zu kopieren, ausgegeben wird.

Quelle: opennet.ru