Git 2.41 Versionsverwaltungssystem verfügbar

Nach drei Monaten Entwicklungszeit wurde das Release des verteilten Versionsverwaltungssystems Git 2.41 veröffentlicht. Git ist eines der beliebtesten, zuverlässigsten und leistungsstärksten Versionskontrollsysteme, das flexible nichtlineare Entwicklungstools basierend auf Verzweigungen und Zusammenführungen von Zweigen bereitstellt. 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 der Entwickler zu überprüfen.

Im Vergleich zur Vorgängerversion wurden 542 Änderungen in die neue Version übernommen, die unter Beteiligung von 95 Entwicklern erstellt wurde, von denen 29 erstmals an der Entwicklung beteiligt waren. Wichtigste Neuerungen:

• Verbesserte Handhabung nicht erreichbarer Objekte, auf die im Repository nicht verwiesen wird (Zweige oder Tags werden nicht referenziert). Nicht erreichbare Objekte werden vom Garbage Collector entfernt, verbleiben jedoch vor dem Entfernen eine bestimmte Zeit lang im Repository, um Race Conditions zu vermeiden. Um den Zeitraum nicht erreichbarer Objekte im Auge zu behalten, ist es notwendig, Etiketten mit der Änderungszeit ähnlicher Objekte an sie zu binden, was ihre Speicherung in einer Packdatei, in der alle Objekte eine gemeinsame Änderungszeit haben, nicht zulässt. Bisher wurde jedes nicht erreichbare Objekt in einer separaten Datei gespeichert, was zu Problemen führte, wenn eine große Anzahl neuer nicht erreichbarer Objekte vorhanden war, die noch nicht gelöscht werden mussten. In der neuen Version wird standardmäßig der „Cruft Packs“-Mechanismus zum Packen nicht erreichbarer Objekte verwendet, der es ermöglicht, alle nicht erreichbaren Objekte in einer Packdatei zu speichern und die Daten zur Änderungszeit jedes Objekts in einer separaten Tabelle wiederzugeben, die in einem gespeichert ist Datei mit der Erweiterung „.mtimes“ erstellt und über eine Indexdatei mit der Erweiterung „.idx“ verknüpft.
• Standardmäßig ist die Verwaltung eines umgekehrten Index (revindex) auf der Festplatte für Packdateien aktiviert. Bei Tests in den Torvalds/Linux-Repositories konnten wir durch die Verwendung eines Reverse-Index ressourcenintensive „Git Push“-Vorgänge um das 1.49-fache beschleunigen und einfache Vorgänge wie die Berechnung der Größe eines einzelnen Objekts mithilfe von „Git Cat“ um das 77-fache beschleunigen. file --batch='%(objectsize:disk)' » XNUMX Mal. Dateien („.rev“) mit einem umgekehrten Index werden im Repository im Verzeichnis „.git/objects/pack“ gespeichert.

  Denken Sie 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 Objekte zusätzlich in Packdateien abgelegt, in denen Informationen in Form eines Stroms von nacheinander aufeinanderfolgenden Objekten dargestellt werden (ein ähnliches Format wird beim Übertragen von Objekten mit git fetch und git verwendet Push-Befehle). Für jede Packdatei wird eine Indexdatei (.idx) erstellt, mit der Sie sehr schnell den Offset in der Packdatei ermitteln können, mit dem das angegebene Objekt durch die Objektkennung gespeichert wird.

  Der in der neuen Version enthaltene Reverse-Index soll den Prozess der Ermittlung der Objekt-ID anhand von Informationen über den Speicherort des Objekts in der Packdatei rationalisieren. Zuvor wurde eine solche Konvertierung spontan während des Parsens der Packdatei durchgeführt und nur im Speicher gespeichert, was eine Wiederverwendung solcher Indizes nicht zuließ und die Erstellung des Index jedes Mal erzwang. Der Vorgang zum Erstellen eines Index beschränkt sich auf den Aufbau eines Arrays von Objekt-Positions-Paaren und dessen Sortierung nach Position, was bei großen Paketdateien viel Zeit in Anspruch nehmen kann.

  Beispielsweise war die Anzeige des Inhalts von Objekten, die einen direkten Index verwendet, 62-mal schneller als die Anzeige der Größe von Objekten, für die die Positions-zu-Objekt-Beziehungsdaten nicht indiziert waren. Nach Verwendung des umgekehrten Index dauerten diese Vorgänge ungefähr gleich lange. Mit Reverse-Indizes können Sie auch den Vorgang des Sendens von Objekten bei der Ausführung von Abruf- und Push-Befehlen beschleunigen, indem Sie vorgefertigte Daten direkt von der Festplatte übertragen.

  

• Unterstützung für die Weitergabe von WWW-Authenticate-Headern zwischen dem Anmeldeinformations-Handler und dem Authentifizierungsdienst an das „Credential Helper“-Protokoll hinzugefügt, das zur Weitergabe von Anmeldeinformationen beim Zugriff auf eingeschränkte Repositorys verwendet wird. Durch die Unterstützung des WWW-Authenticate-Headers können Sie OAuth-Bereichsparameter übergeben, um den Benutzerzugriff auf Repositorys detaillierter zu trennen und die für Anforderungen verfügbaren Bereiche abzugrenzen.
• Formatoption „%(ahead-behind:“ hinzugefügt )“, mit dem Sie sofort Informationen über die Anzahl der in einem bestimmten Zweig vorhandenen oder fehlenden Commits im Vergleich zu einem anderen Zweig erhalten können (wie viel ein Zweig auf der Ebene der Commits hinter oder vor einem anderen zurückbleibt). Bisher waren zum Abrufen dieser Informationen zwei separate Befehle erforderlich: „git rev-list --count main..my-feature“, um die Anzahl der für einen Zweig eindeutigen Commits zu ermitteln, und „git rev-list --count my-feature.. main“, um die Anzahl der fehlenden Commits zu ermitteln. Jetzt können solche Berechnungen auf eine einzige Anweisung reduziert werden, was das Schreiben von Handlern vereinfacht und die Ausführungszeit verkürzt. Um beispielsweise nicht zusammengeführte Zweige anzuzeigen und zu bewerten, ob sie hinter oder vor ihrem Hauptzweig liegen, können Sie einen Einzeiler verwenden: $ git for-each-ref --no-merged=origin/HEAD \ --format=' %(refname:short) %(ahead-behind :origin/HEAD)' \ refs/heads/tb/ | Spalte -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 ist: $ 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" erledigt | Spalte -t ​​tb/cruft-extra-tips 2 96 tb/for-each-ref – ausschließen 16 96 tb/roaring-bitmaps 47 3
• Option „--porcelain“ zum Befehl „git fetch“ hinzugefügt, die eine Ausgabe im Format „generiert“ “, weniger lesbar, aber bequemer zum Parsen in Skripten.
• Die Einstellung „fetch.hideRefs“ wurde hinzugefügt, um „git fetch“-Vorgänge zu beschleunigen, indem ein Teil der Links im lokalen Repository ausgeblendet wird, während überprüft wird, ob der Server den vollständigen Satz an Objekten gesendet hat. Dies spart Zeit, da die Überprüfung nur auf Server beschränkt wird von dem Daten direkt abgerufen werden. Beim Testen beispielsweise auf einem System mit Repositorys, die eine große Anzahl verfolgter externer Links enthalten, konnte durch Ausschließen aller Links außer denen, die an den $remote-Zielserver gerichtet waren, der „git fetch“-Vorgang von 20 Minuten auf 30 Sekunden reduziert werden. $ git -c fetch.hideRefs=refs -c fetch.hideRefs=!refs/remotes/$remote \ fetch $remote
• Der Befehl „git fsck“ implementiert die Möglichkeit, in Barrierefreiheits-Bitmaps und Reverse-Indizes auf Korruption, Prüfsummenübereinstimmung und Richtigkeit von Werten zu prüfen.
• Der Befehl „git clone --local“ zeigt jetzt einen Fehler an, wenn versucht wird, aus einem Repository zu kopieren, das symbolische Links in $GIT_DIR enthält.

Source: opennet.ru