Veröffentlichung des Versionskontrollsystems Git 2.54

Die neueste Version des verteilten Versionskontrollsystems Git 2.54 wurde veröffentlicht. Git zeichnet sich durch hohe Leistung aus und bietet Werkzeuge für die nichtlineare Entwicklung, die auf Branching und Merging basieren. Um die Integrität der Historie und die Resistenz gegenüber rückwirkenden Änderungen sicherzustellen, wird eine implizite Hash-Berechnung der gesamten vorherigen Historie in jedem Commit verwendet, sowie die digitale Signierung durch die Entwickler einzelner Tags und Commits. Der Git-Code wird unter der GPLv2+-Lizenz verbreitet.

Im Vergleich zur vorherigen Version wurden 770 Änderungen in die neue Version aufgenommen, die von 137 Entwicklern vorbereitet wurden (66 davon haben zum ersten Mal an der Entwicklung von Git mitgewirkt). Die wesentlichen Neuerungen sind:

• Die Funktion "git history" wurde implementiert und bietet experimentelle Möglichkeiten zur Neuordnung der Änderungs historie, die einfacher und sicherer zu verwenden sind als das Rebase von Commits mit dem Befehl "git rebase". Es stehen zwei Operationen zur Verfügung:
  • Mit «git history reword <commit>» können Sie die Nachricht eines bestimmten Commits ändern, ohne dabei den Arbeitsbaum und den Index zu beeinflussen (außer für die Notiz, der Rest bleibt unverändert). Zum Beispiel zur Korrektur eines Schreibfehlers.
  • Mit «git history split <commit>» können Sie einen bestimmten Commit interaktiv in zwei unterschiedliche Commits aufteilen, wobei ausgewählte Teile vom ursprünglichen Commit in den zusätzlichen Commit verschoben werden.

  In zukünftigen Versionen sind zusätzliche Befehle geplant: «git history fixup» zur Korrektur eines Commits, «git history drop» zum Löschen eines Commits, «git history reorder» zur Änderung der Reihenfolge der Commits und «git history squash» zum Zusammenführen von Commits.
• Eine neue Methode zur Definition von Hooks in Konfigurationsdateien wurde implementiert. Anstelle von Skripten für Hooks im Verzeichnis ".git/hooks" in jedem Repository, können die Befehle zum Aufruf der Hooks nun direkt in den Konfigurationsdateien angegeben werden. Einstellungen können entweder an ein spezifisches Repository gebunden oder in Konfigurationsdateien festgelegt werden, die für alle Repositories gelten (/etc/gitconfig) oder für Benutzerdaten (/~/.gitconfig). Es ist möglich, mehrere Hooks an ein einzelnes Ereignis zu binden. Skripte aus ".git/hooks" werden weiterhin aufgerufen, jedoch nach den Hooks aus den Konfigurationsdateien. Um die Liste der Hooks anzuzeigen, verwenden Sie den Befehl „git hook list“, und um den Aufruf bestimmter Hooks selectively zu deaktivieren, nutzen Sie die Einstellung „hook..enabled = false“. [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 Team "git maintenance" wird standardmäßig die Strategie "geometric" verwendet ("git config set maintenance.strategy geometric"), um die Wartungszeiten großer Monorepositories zu verkürzen. Im Vergleich zu der zuvor angewandten Strategie, die ähnliche Logik wie im Befehl "git gc" verwendet, vermeidet die neue Strategie das Neupacken aller Objekte und schließt ressourcenintensive Operationen wie das Zusammenführen aller Packdateien aus (sofern möglich erfolgt die Zusammenführung schrittweise und ohne Bereinigung von entfernten Objekten).
• Die Objektdatenbank (ODB) und die damit verbundenen APIs wurden auf eine neue Architektur umgestellt, die auf der Verwendung von plug-in Backends basiert. Die durchgeführte Restrukturierung abstrahiert das Format der Objektspeicherung und ermöglicht in Zukunft Funktionen wie alternative Backends und Objektformate, zum Beispiel für eine effizientere Speicherung großer Binärdateien oder zur Optimierung des Betriebs großer Git-Hosting-Anbieter.
• Im Befehl „git repo structure“, der Informationen zur Struktur des Repositories liefert, wird nicht nur die Gesamtgröße angezeigt, sondern auch die größten Objekte jeder Art werden dargestellt. Dies ermöglicht eine Größenbewertung ohne die Verwendung des externen Tools git-sizer. $ 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 Befehl „git replay“, der anstelle von „git rebase“ verwendet wird, um die Historie zu reproduzieren, Server ohne Arbeitsverzeichnis ist standardmäßig ein atomisches Update der Referenzen aktiviert (anstatt einer Liste von update-ref-Befehlen zur manuellen Ausführung). Es wurde die Option „—revert“ hinzugefügt, um Änderungen aus einer Reihe von Commits rückgängig zu machen, um leere Commits zu verwerfen, und es gibt die Möglichkeit, die Historie bis hin zum Root-Commit wiederherzustellen.
• In „git rev-list“ und ähnlichen Befehlen wurde die Option „—maximal-only“ hinzugefügt, um nur Commits anzuzeigen, die von anderen Commits nicht erreichbar sind.
• Dem Befehl «git repo info» wurde die Option «—keys» hinzugefügt, um eine Liste aller bekannten Schlüssel auszugeben.
• Im Befehl «git add -p» wird beim Navigieren zwischen Codeblöcken mit den Tasten «J» und «K» angezeigt, welche Blöcke bereits genehmigt oder übersprungen wurden. Eine Option «—no-auto-advance» wurde hinzugefügt, um das automatische Voranschreiten zum nächsten Datei zu deaktivieren, sodass man zu vorherigen Dateien vor dem Commit zurückkehren kann.
• Die Weboberfläche «gitweb» wurde für die Nutzung auf mobilen Geräten optimiert.
• Im Befehl «git apply —directory» erfolgt vor der Nutzung eine Normalisierung der Dateipfade, wie «./un/../normalized/path».
• Die Möglichkeit zur Hinzufügung eigener Unterbefehle durch das Platzieren von Dateien «git-<cmd>» im Verzeichnis der ausführbaren Dateien wurde dokumentiert.
• Dem 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, mit der die Branches angegeben werden können, mit denen der aktuelle Branch verglichen werden soll. [status] compareBranches = @{upstream} @{push}
• Dem Befehl «git rebase» wurde die Option «—trailer» hinzugefügt, die das Hinzufügen von Metadaten zu allen Commits erleichtert. git rebase —trailer «Reviewed-by: Test <test@example.com>»
• Das Team „git fast-import“ hat die Möglichkeit hinzugefügt, Signaturen für Commits zu ersetzen, die nach dem Import ungültig geworden sind.
• Es wurde Unterstützung für die Komprimierung (Compaction) von Multi-Pack-Indexes (MIDX) hinzugefügt, bei der kleinere MIDX-Indexschichten mit Informationen zur Verfügbarkeit von Objekten und zugehörigen Bitmap-Dateien zusammengeführt werden, wodurch die Anzahl der angesammelten Schichten in lange bestehenden Repositories reduziert wird.
• Im Team „git backfill“ wurde die Möglichkeit implementiert, Revisionen (Commit-Bereiche) und Pfadmuster (pathspec) anzugeben, um die zu ladenden Teile der Änderungs historie einzuschränken. git backfill main~100..main git backfill — ‘*.c’
• Alternativ können die Befehlsaufrufe für „git config list“ verwendet werden: „git config -l“ und „git config —list“.
• Die Verwendung von Nicht-ASCII-Zeichen in den Namen der Befehlsalias im Konfigurationsdatei ist erlaubt. [alias „holen“] command = fetch
• Die Anzeige von Signaturen wurde geändert, deren GPG-Schlüssel abgelaufen sind, die jedoch zum Zeitpunkt der Signierung des Commits gültig waren. Solche Signaturen werden jetzt als gültig angezeigt, mit einem Hinweis auf den abgelaufenen Schlüssel (früher wurden sie rot hervorgehoben, was den Eindruck von Ungültigkeit erweckte).
• Bei der Anfrage an Repositories über HTTP wurde die Fehlerbehandlung für den Code 429 (Too Many Requests) implementiert. Anfragen, die mit diesem Fehler enden, werden nicht mehr als schwerwiegendes Problem betrachtet, sondern als vorübergehender Fehler, für den die operation nach einer gewissen Zeit wiederholt werden sollte. Die Verzögerung vor dem erneuten Versuch kann über die Option „http.retryAfter“ eingestellt werden, die Anzahl der Wiederholungen über „http.maxRetries“ und die Wartezeit über „http.maxRetryTime“.

Quelle: opennet.ru