Git 2.54

Git 2.54

Präsentiert Release des verteilten Systems zur Verwaltung von Quelltexten Git 2.54. Git bietet hohe Leistungsfähigkeit und stellt Werkzeuge für nichtlineare Entwicklungen bereit, die auf Branching und Merging basieren. Um die Integrität der Historie und die Robustheit gegenüber nachträglichen Änderungen zu gewährleisten, verwendet Git implizite Hashes der gesamten vorherigen Historie in jedem Commit sowie digitale Signaturen der Entwickler für einzelne Tags und Commits. Code Git wird unter der GPLv3-Lizenz bereitgestellt. steht unter der GPLv2+ Lizenz.

Im Vergleich zur vorherigen Version wurden 770 Änderungen übernommen, die mit der Mitwirkung von 137 Entwicklern erstellt wurden (darunter 66, die erstmals an der Entwicklung von Git beteiligt sind).

Haupt Neuheiten:

  • Es wurde der Befehl «git history» implementiert, der experimentelle Funktionen für das Umschreiben der Änderungs-Historie 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 Umschreiben der Nachricht im angegebenen Commit, ohne das Arbeitsverzeichnis und den Index zu ändern (außer der Notiz, der Rest bleibt unverändert). Zum Beispiel, um einen Tippfehler zu korrigieren.
    • git history split für die interaktive Trennung des angegebenen Commits in zwei verschiedene Commits, indem ausgewählte Teile vom ursprünglichen Commit in einen zusätzlichen Commit verschoben werden.

    In zukünftigen Releases 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 von Commits und git history squash zum Zusammenführen von Commits.

  • Eine neue Methode zur Bestimmung von Handlern wurde implementiert (Hook) in den Konfigurationsdateien. Anstelle von Skripten mit Handlern im Verzeichnis .git/hooks in jedem Repository können die Befehle zum Aufrufen der Handler jetzt direkt in den Konfigurationsdateien festgelegt werden. Die Einstellungen können an das Repository gebunden oder in den 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 ausgelöst, laufen jedoch nach den Handlern aus den Konfigurationsdateien. Um die Liste der Handler anzuzeigen, sollte der Befehl git hook list verwendet werden, und um das gezielte Deaktivieren des Aufrufs von Handlern vorzunehmen, ist die Einstellung hook..enabled = false erforderlich:

[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

  • In dem Befehl „git maintenanceStandardmäßig ist die Strategie geometric aktiviert (git config set maintenance.strategy geometric), die die Wartungszeiten großer Monorepositories reduziert. Im Vergleich zur vorher verwendeten Strategie, die eine Logik ähnlich der des git gc-Befehls nutzt, vermeidet die neue Strategie das Neupacken aller Objekte und schließt ressourcenintensive Operationen wie das Zusammenführen aller Pack-Dateien aus (sofern möglich erfolgt die Zusammenführung in Teilen und ohne Bereinigung gelöschter Objekte).
  • Die Objektdatenbank (ODB) und die zugehörigen APIs wurden auf eine neue Architektur umgestellt, die auf der Nutzung von erweiterbaren Backends basiert. Die durchgeführte Umstrukturierung abstrahiert das Speicherformat der Objekte und wird in Zukunft die Implementierung von Funktionen wie alternativen Backends und Objektformaten ermöglichen, beispielsweise für eine effizientere Speicherung großer Binärdateien oder zur Optimierung der Arbeit großer Git-Hosting-Anbieter.
  • In dem Befehl „git repo structure», die Informationen zur Struktur des Repositories anzeigt, bietet die Darstellung nicht nur der Gesamtsumme, sondern auch der größten Objekte jeder Art, was eine Bewertung der Größe ohne den Einsatz eines externen Tools ermöglicht. 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 |

  • In dem Befehl „git replay», die anstelle von git rebase verwendet wird, um die Historie auf dem Server ohne Arbeitsverzeichnis nachzubilden, beinhaltet standardmäßig atomare Aktualisierungen der Referenzen (anstatt eine Liste von update-ref-Befehlen zur manuellen Ausführung auszugeben), implementierte die Option —revert zum Rückgängigmachen von Änderungen einer Reihe von Commits, stellt das Abwerfen resultierender leerer Commits sicher und bietet die Möglichkeit, die Historie bis zum Wurzelcommit wiederherzustellen.
  • In „git rev-list“ und ähnliche Befehle wurde die Option —maximal-only hinzugefügt, um nur die Commits anzuzeigen, die von anderen Commits nicht erreicht werden können.
  • Zum Befehl „git repo info» Die Option —keys wurde hinzugefügt, um eine Liste aller bekannten Schlüssel anzuzeigen.
  • In dem Befehl „git add -p» Beim Navigieren zwischen Code-Blöcken mit den Tasten «J» und «K» wird nun eine Markierung für bereits genehmigte und übersprungene Blöcke bereitgestellt. Eine Option —no-auto-advance wurde hinzugefügt, um den automatischen Übergang zur nächsten Datei zu deaktivieren, sodass es möglich ist, zu früheren Dateien vor dem Commit zurückzukehren.
  • Die web-basierte Benutzeroberfläche „gitweb“ wurde für die Nutzung auf mobilen Geräten optimiert.
  • In dem Befehl „git apply –directory» Vor der Verwendung wird eine Normalisierung von Dateipfaden wie ./un/../normalized/path gewährleistet.
  • Die Möglichkeit zur Hinzufügung eigener Unterbefehle wurde dokumentiert, indem Dateien git- im Verzeichnis mit den ausführbaren Dateien platziert werden.
  • Zum Befehl „git send-email» Unterstützung für Client-Zertifikate wurde hinzugefügt.
  • Für den Befehl „git status“ wurde die Einstellung status.compareBranches implementiert, über die festgelegt werden kann, mit welchen Branches der aktuelle Branch verglichen werden soll:

[status] compareBranches = @{upstream} @{push}

  • In „git rebase» Die Option —trailer wurde hinzugefügt, um das Hinzufügen von Metadaten zu allen Commits zu vereinfachen:

git rebase —trailer "Reviewed-by: Test "`

  • Zum Befehl „git fast-import» Die Möglichkeit, die Beschriftungen für Commits zu ersetzen, die nach dem Import ungültig wurden, wurde hinzugefügt.
  • Die Unterstützung für die Komprimierung (Compaction) von Mehrpack-Indexen (MIDX) wurde eingeführt. Dabei werden kleine Schichten von MIDX-Indizes zusammengeführt, die Informationen über die Verfügbarkeit von Objekten und die zugehörigen Bitmap-Dateien enthalten. Dies reduziert die Anzahl der angesammelten Schichten in älteren Repositories.
  • Im git backfill-Befehl wurde die Möglichkeit hinzugefügt, Revisionen (Commit-Bereiche) und Pfadmasken (pathspec) anzugeben, um die geladenen Teile der Änderungshistorie einzuschränken:

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

  • Alternative Aufrufmethoden für den git config list-Befehl wurden hinzugefügt – git config -l und git config —list.
  • Die Verwendung von nicht-ASCII-Zeichen in den Namen von Aliasen, die in der Konfigurationsdatei festgelegt sind, ist jetzt erlaubt:

[alias "fetch"] 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 HTTP-Anfragen wurden Fehler mit dem Code 429 (Zu viele Anfragen) nun ordnungsgemäß behandelt. Anfragen, die mit diesem Fehler beendet wurden, werden nicht mehr als fatales Problem betrachtet, sondern als vorübergehender Fehler, für den die Operation nach einer gewissen Zeit wiederholt werden sollte. Die Verzögerung vor dem Wiederholen wird durch die Option http.retryAfter, die Anzahl der Wiederholungen durch http.maxRetries und die Wartezeit durch http.maxRetryTime festgelegt.

Quelle: linux.org.ru

Zuverlässiges Hosting für Websites mit DDoS-Schutz, VPS VDS-Servern kaufen 🔥 Kaufen Sie zuverlässiges Hosting für Websites mit DDoS-Schutz, VPS VDS-Servern | ProHoster