Veröffentlichung des Textmanagementsystems Git 2.54

Die Veröffentlichung des verteilten Systems zur Verwaltung von Quelltexten Git 2.54 wurde vorgestellt. Git zeichnet sich durch hohe Leistungsfähigkeit aus und bietet Mittel für die nichtlineare Entwicklung, die auf dem Branching und dem Merging von Zweigen basieren. Um die Integrität der Historie und die Robustheit gegenüber nachträglichen Änderungen zu gewährleisten, werden implizite Hashes der gesamten vorhergehenden Geschichte in jedem Commit verwendet, sowie digitale Signaturen von Entwicklern für bestimmte Tags und Commits. Der Git-Code wird unter der GPLv2+-Lizenz verbreitet.

Im Vergleich zur vorherigen Version wurden 770 Änderungen vorgenommen, die mit der Beteiligung von 137 Entwicklern (66 von ihnen zum ersten Mal in der Entwicklung von Git) vorbereitet wurden. Die wichtigsten Neuerungen sind:

• Das Kommando „git history“ wurde implementiert, das experimentelle Möglichkeiten zur Neufassung der Änderungsgeschichte bietet, die einfacher und sicherer zu verwenden sind als das Rebasieren von Commits mit dem Befehl „git rebase“. Es werden zwei Operationen bereitgestellt:
  • „git history reword <commit>“ zum Ändern der Nachricht im angegebenen Commit, ohne das Arbeitsverzeichnis und den Index zu verändern (außer der Anmerkung bleibt der Rest unberührt). Zum Beispiel zur Korrektur eines Tippfehlers.
  • „git history split <commit>“ zum interaktiven Aufteilen des angegebenen Commits in zwei verschiedene Commits, bei dem ausgewählte Teile aus dem ursprünglichen Commit in einen zusätzlichen Commit verschoben werden.

  In zukünftigen Versionen wird die Hinzufügung weiterer Befehle erwartet: „git history fixup“ zum Korrigieren eines Commits, „git history drop“ zum Löschen eines Commits, „git history reorder“ zum Ändern der Reihenfolge der Commits und „git history squash“ zum Zusammenführen von Commits.
• Eine neue Methode zur Bestimmung von Hooks in Konfigurationsdateien wurde implementiert. Anstatt Skripte mit Hooks im Verzeichnis „.git/hooks“ in jedem Repository unterzubringen, können die Befehle zum Aufrufen der Hooks jetzt direkt in den Konfigurationsdateien angegeben werden. Die Einstellungen können entweder an das Repository gebunden oder in Konfigurationsdateien angegeben werden, die für alle Repositories gelten (/etc/gitconfig) oder für das Benutzer-Repository (~/.gitconfig). Es ist möglich, mehrere Hooks an ein Ereignis zu binden. Skripte aus „.git/hooks“ werden weiterhin aufgerufen, jedoch nach den Hooks aus den Konfigurationsdateien. Für die Anzeige der Liste der Hooks sollte der Befehl „git hook list“ verwendet werden, und um die Ausführung bestimmter Hooks zu deaktivieren, sollte die Einstellung „hook..enabled = false“ verwendet werden. [hook „linter“] event = pre-commit command = ~/.bin/linter —cpp20 [hook „no-leaks“] event = pre-commit command = ~/.bin/leak-detector $ git hook list pre-commit global linter ~/.bin/linter —cpp20 local no-leaks ~/.bin/leak-detector
• Im Befehl „git maintenance“ ist standardmäßig die Strategie „geometric“ aktiviert („git config set maintenance.strategy geometric“), die dazu beiträgt, die Wartungszeit großer Monorepositories zu verkürzen. Im Vergleich zur zuvor verwendeten Strategie, die die Logik im Befehl „git gc“ anwendet, vermeidet die neue Strategie die Neupackung aller Objekte und schließt ressourcenintensive Operationen wie das Zusammenführen aller Pack-Dateien aus (wenn möglich erfolgt die Zusammenführung schrittweise und ohne Bereinigung gelöschter Objekte).
• Die Objektdatenbank (ODB) und die zugehörigen APIs wurden auf eine neue Architektur umgestellt, die auf der Verwendung von Plug-in-Backends basiert. Die durchgeführte Umstrukturierung abstrahiert das Objektstorage-Format und wird es in Zukunft ermöglichen, solche Funktionen wie alternative Backends und Objektformate zu implementieren, zum Beispiel für eine effizientere Speicherung großer Binärdateien oder zur Optimierung des Betriebs großer Git-Hosting-Dienste.
• Im Team „git repo structure“, das Informationen über die Struktur des Repositories ausgibt, werden nicht nur die Gesamtgröße, sondern auch die größten Objekte jedes Typs angezeigt, was eine Bewertung der Größe ohne die Verwendung des externen Tools git-sizer ermöglicht. $ git repo structure … | * Größte Objekte | | | * Commits | | | * Maximale Größe [1] | 17,23 KiB | | * Maximale Eltern [2] | 10 | | * Bäume | | | * Maximale Größe [3] | 58,85 KiB | | * Maximale Einträge [4] | 1,18 k | | * Blobs | | | * Maximale Größe [5] | 1019,51 KiB | | * Tags | | | * Maximale Größe [6] | 7,13 KiB |
• Im Team „git replay“, das anstelle von „git rebase“ zur Rekonstruktion der Historie verwendet wird, Server ohne Arbeitsverzeichnis ist standardmäßig atomare Aktualisierung der Referenzen aktiviert (anstatt eine Liste von update-ref-Befehlen zur manuellen Ausführung auszugeben). Es wurde die Option „—revert“ für die Rückgängigmachung der Änderungen einer Reihe von Commits implementiert, leere Resultat-Commits werden verworfen, und die Möglichkeit zur Rekonstruktion der Historie bis zum Root-Commit wurde geschaffen.
• In „git rev-list“ und ähnlichen Befehlen wurde die Option „—maximal-only“ hinzugefügt, um nur die von anderen Commits unerreichbaren Commits anzuzeigen.
• In den Befehl „git repo info“ wurde die Option „—keys“ aufgenommen, um eine Liste aller bekannten Schlüssel auszugeben.
• In dem Befehl „git add -p“ wird beim Navigieren zwischen Codeblöcken mit den Tasten „J“ und „K“ die Markierung bereits genehmigter und übersprungener Blöcke ermöglicht. Eine Option „—no-auto-advance“ wurde hinzugefügt, um die automatische Weiterleitung zur nächsten Datei zu deaktivieren, damit man zu vorherigen Dateien vor dem Commit zurückkehren kann.
• Die Web-Oberfläche „gitweb“ wurde für die Nutzung auf Mobilgeräten optimiert.
• Im Befehl „git apply —directory“ wird vor der Verwendung eine Normalisierung der Dateipfade, wie „.\/un\/..\/normalized\/path“, sichergestellt.
• Die Möglichkeit zum Hinzufügen eigener Unterbefehle wurde dokumentiert, indem die Dateien „git-<cmd>“ im Verzeichnis der ausführbaren Dateien platziert werden.
• Im Befehl „git send-email“ wurde die Unterstützung für Client-Zertifikate hinzugefügt.
• Für den Befehl „git status“ wurde die Einstellung „status.compareBranches“ implementiert, über die anzugeben ist, mit welchen Branches der aktuelle Branch verglichen werden soll. [status] compareBranches = @{upstream} @{push}
• In „git rebase“ wurde die Option „—trailer“ hinzugefügt, um das Hinzufügen von Metadaten zu allen Commits zu vereinfachen. git rebase —trailer „Reviewed-by: Test <test@example.com>“
• Das Kommando „git fast-import“ hat die Möglichkeit hinzugefügt, Signaturen für Commits zu ersetzen, die nach dem Import ungültig geworden sind.
• Die Unterstützung für das Verpacken (Komprimierung) von Mehrpack-Indexen (MIDX) wurde hinzugefügt, bei der kleine MIDX-Indexschichten mit Informationen über die Verfügbarkeit von Objekten und zugehörige Bitmap-Dateien zusammengeführt werden, was die Anzahl der angesammelten Schichten in älteren Repositories verringert.
• Im Kommando „git backfill“ wurde die Möglichkeit implementiert, Revisionen (Commit-Bereiche) und Pfadmuster (pathspec) anzugeben, um die herunterzuladenden Teile der Änderungshistorie einzuschränken. git backfill main~100..main git backfill — ‘*.c’
• Alternativen zur Aufrufform des Kommandos „git config list“ wurden hinzugefügt: „git config -l“ und „git config —list“.
• Die Verwendung von Nicht-ASCII-Zeichen in den Aliasnamen von Kommandos, die in der Konfigurationsdatei festgelegt werden, wurde erlaubt. [alias „holen“] command = fetch
• Die Darstellung von Signaturen, deren GPG-Schlüssel abgelaufen ist, aber zum Zeitpunkt der Unterzeichnung des Commits gültig war, wurde geändert. Solche Signaturen werden jetzt als korrekt angezeigt, mit dem Hinweis auf die Veralterung des Schlüssels (früher wurden sie rot hervorgehoben, was den Eindruck vermittelte, sie seien fehlerhaft).
• Bei der Kommunikation mit Repositories über HTTP wird der Fehlercode 429 (Too Many Requests) nun bearbeitet. Anfragen, die mit einem solchen Fehler enden, werden nicht als schwerwiegendes Problem betrachtet, sondern als vorübergehender Fehler, dessen Ausführung nach einiger Zeit wiederholt werden sollte. Die Verzögerung bis zur Wiederholung wird über die Option „http.retryAfter“ festgelegt, die Anzahl der Wiederholungen — „http.maxRetries“, die Wartezeit — „http.maxRetryTime“.

Quelle: opennet.ru