🥇Git 2.54 | ProHoster

Vorstellung Release des verteilten Versionskontrollsystems Git 2.54. Git zeichnet sich durch hohe Leistung aus und bietet Mittel für nichtlineare Entwicklung, die auf Branching und Merging basieren. Um die Integrität der Historie und die Widerstandsfähigkeit gegen "Retroaktivität" zu gewährleisten, wird das gesamte vorherige Geschehen in jedem Commit implizit gehasht, und (digitale) Signaturen der Entwickler für einzelne Tags und Commits werden verwendet. Git-Code wird verbreitet unter der GPLv2+-Lizenz.

Im Vergleich zur vorherigen Version wurden 770 Änderungen für die neue Version übernommen, die von 137 Entwicklern (davon 66 erstmals an der Entwicklung von Git beteiligt) vorbereitet wurden.

Haupt- Neuheiten:

Der Befehl „git history“ wurde eingeführt, um experimentelle Möglichkeiten zur Neuschreibung von Änderungsprotokollen bereitzustellen, die einfacher und sicherer in der Anwendung sind als das Rebasen von Commits mit dem Befehl git rebase. Zwei Operationen werden bereitgestellt:
- git history reword zur Neuschreibung der Nachricht im angegebenen Commit, ohne das Arbeitsverzeichnis und den Index zu verändern (außer der Notiz, der Rest bleibt unangetastet). Zum Beispiel zum Beheben eines Tippfehlers.
- git history split zum interaktiven Aufteilen des angegebenen Commits in zwei verschiedene Commits, wobei ausgewählte Teile aus dem ursprünglichen Commit in den zusätzlichen Commit verschoben werden.
In zukünftigen Veröffentlichungen ist die Hinzufügung weiterer Befehle geplant: git history fixup zur Korrektur eines Commits, git history drop zum Löschen eines Commits, git history reorder zum Ändern der Reihenfolge von Commits und git history squash zum Kombinieren von Commits.
Eine neue Methode zur Definition von Hooks wurde realisiert (hook) in den Konfigurationsdateien. Anstelle von Skripten mit Handlern im Verzeichnis .git/hooks in jedem Repository, können die Befehle zur Ausführung von Handlern jetzt direkt in den Konfigurationsdateien festgelegt werden. Einstellungen können 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 Handler an ein Ereignis zu binden. Skripte aus .git/hooks werden weiterhin aufgerufen, jedoch werden sie nach den Handlern aus den Konfigurationsdateien gestartet. Um die Liste der Handler anzuzeigen, sollte der Befehl git hook list verwendet werden, und um die Ausführung bestimmter Handler selektiv zu deaktivieren – 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 Befehl „git maintenance“ ist standardmäßig die Strategie geometric aktiviert (git config set maintenance.strategy geometric), die es ermöglicht, die Wartungszeit großer Monorepositories zu verkürzen. Im Vergleich zur zuvor verwendeten Strategie, die die Logik des Befehls git gc verwendete, vermeidet die neue Strategie die Neuverpackung aller Objekte und schließt übermäßig ressourcenintensive Operationen wie das Zusammenführen aller Packdateien aus (wenn möglich, erfolgt die Zusammenführung in Teilen und ohne Bereinigung der gelöschten Objekte).
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 Umstrukturierung abstrahiert das Format der Objektspeicherung und wird in Zukunft solche Möglichkeiten wie alternative Backends und Objektformate ermöglichen, beispielsweise für eine effizientere Speicherung großer Binärdateien oder zur Optimierung der Arbeit großer Git-Hosting-Anbieter.
Im Befehl „git repo structure“, die Informationen über die Struktur des Repositories ausgibt, zeigt nicht nur die Gesamgröße an, sondern auch die größten Objekte jedes Typs, was ermöglicht, bei der Größenschätzung ohne den Einsatz eines externen Werkzeugs auszukommen. git-sizer.

Im Befehl „git replay», die anstelle von git rebase verwendet wird, um die Historie auf dem Server ohne Arbeitsverzeichnis neu zu erstellen, ist standardmäßig ein atomares Aktualisieren der Referenzen aktiviert (anstatt eine Liste von update-ref-Befehlen zur manuellen Ausführung auszugeben), es wurde die Option —revert implementiert, um Änderungen aus einer Reihe von Commits rückgängig zu machen, und es wird sichergestellt, dass leere Commits nach dem Ergebnis verworfen werden können, sowie die Möglichkeit geschaffen, die Historie bis zum Wurzel-Commit neu zu erstellen.
In „git rev-list» und ähnlichen Befehlen wurde die Option —maximal-only hinzugefügt, um nur die Commits anzuzeigen, die von anderen Commits nicht erreicht werden können.
Im Befehl „git repo info» wurde die Option —keys hinzugefügt, um eine Liste aller bekannten Schlüsseln auszugeben.
Im Befehl „git add -p» wurde beim Navigieren zwischen den Codeblöcken mit den Tasten „J“ und „K“ angezeigt, welche bereits genehmigten und übersprungenen Blöcke markiert sind. Die Option —no-auto-advance wurde hinzugefügt, um das automatische Wechseln zur nächsten Datei zu deaktivieren, sodass man vor dem Commit zu früheren Dateien zurückkehren kann.
Der Web-Interface „gitweb» wurde für die Nutzung von mobilen Geräten optimiert.
Im Befehl „git apply –directory» stellt sicher, dass die Dateipfade, wie z. B. .\/un\/..\/normalized\/path, vor der Verwendung normalisiert werden.
Die Möglichkeit, eigene Unterkommandos durch das Platzieren von Dateien git-<cmd> im Verzeichnis mit den ausführbaren Dateien hinzuzufügen, wurde dokumentiert.
Im Befehl „git send-email» unterstützt jetzt Client-Zertifikate.
Für den Befehl „git status» wurde die Konfiguration status.compareBranches implementiert, mit der angegeben werden kann, 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 erleichtern:

git rebase —trailer "Reviewed-by: Test <test@example.com>"`

Im Befehl „git fast-import» wurde die Möglichkeit hinzugefügt, Signaturen für Commits zu ersetzen, die nach dem Import ungültig geworden sind.
Die Unterstützung der Verpackung (Compaction) von Multi-Pack-Indexes MIDX wurde hinzugefügt, wobei kleine Schichten des MIDX-Indexes mit Informationen zur Verfügbarkeit von Objekten und den zugehörigen Bitmap-Dateien zusammengeführt werden. Dies reduziert die Anzahl der angesammelten Schichten in langjährigen Repositories.
Im git backfill-Befehl wurde die Möglichkeit implementiert, Revisionen (Commit-Bereiche) und Pfadmasken (pathspec) zur Eingrenzung der zu ladenden Teile der Änderungshistorie anzugeben:

git backfill main~100..main git backfill — ‘*.c’

Alternative Aufrufformen des Kommandos git config list wurden hinzugefügt – git config -l und git config —list.
Die Verwendung von Nicht-ASCII-Zeichen in den Alias-Namen für Befehle, die in der Konfigurationsdatei festgelegt werden, ist 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).
Beim Zugriff auf Repositories über HTTP wurde die Behandlung des Fehlers mit dem Code 429 (Too Many Requests) gewährleistet. Anfragen, die mit diesem Fehler abgeschlossen wurden, werden jetzt nicht als schwerwiegendes Problem betrachtet, sondern als vorübergehender Fehler, bei dem die Operation nach einer bestimmten Zeit wiederholt werden sollte. Die Verzögerung vor der Wiederholung wird über die Option http.retryAfter festgelegt, die Anzahl der Wiederholungen – http.maxRetries, die Wartezeit – http.maxRetryTime.

Quelle: linux.org.ru