Die neue Version des Versionsverwaltungssystems Git 2.52 ist erschienen.

Nach drei Monaten Entwicklung wurde die Version 2.52 des verteilten Systems zur Verwaltung von Quelltexten Git veröffentlicht. Git zeichnet sich durch hohe Leistungsfähigkeit aus und bietet Werkzeuge für die nichtlineare Entwicklung, die auf Verzweigung und Zusammenführung von Branches basieren. Um die Integrität der Historie und die Widerstandsfähigkeit gegen nachträgliche Änderungen zu gewährleisten, wird eine implizite Hashierung der gesamten vorherigen Historie in jedem Commit verwendet sowie die Verifizierung durch digitale Signaturen der Entwickler für bestimmte Tags und Commits. Der Git-Code wird unter der GPLv2+ Lizenz verbreitet.

Im Vergleich zur vorherigen Version wurden in die neue Version 637 Änderungen aufgenommen, die mit der Beteiligung von 94 Entwicklern vorbereitet wurden (33 nahmen erstmals an der Entwicklung von Git teil). Wichtige Neuerungen (1, 2, 3):

• Der Befehl „git last-modified“ wurde hinzugefügt, um eine Liste von Dateien in der angegebenen Revision sowie der Commits anzuzeigen, die die letzten Änderungen an jeder dieser Dateien vorgenommen haben. $ git last-modified HEAD b56f6dcd7b4c90192018e848d0810f091d092913 test.h 29330ae4b820147c98e723399e9438c8bee60a8a test1.c 573ad8917beb99dc643b6e7f5c117a294384a575 test2.c
• Der Befehl „git repo“ wurde hinzugefügt, um Aktionen zum Abrufen von Informationen aus einem Repository auszuführen. Zwei Unterbefehle wurden vorgeschlagen – „git repo info“ und „git repo structure“, die Informationen über die Repository-Einstellungen und die Struktur des Repositories ausgeben (zum Beispiel kann festgestellt werden, wie viele Referenzen und Objekte sich im Repository befinden). $ git repo info object.format references.format object.format=sha1 references.format=reftable $ git repo structure | Repository-Struktur | Wert | | ————————— | ——— | | * Referenzen | | | * Anzahl | 1983 | | * Branches | 4 | | * Tags | 1125 | | * Remotes | 854 | | * Sonstige | 0 | | | | | * Erreichbare Objekte | | | * Anzahl | 518955 | | * Commits | 77469 | | * Trees | 188865 | | * Blobs | 251631 | | * Tags | 990 |
• Dem Befehl „git refs“ wurden drei Unterbefehle hinzugefügt, die disparate und sich überschneidende Low-Level-Operationen auf Referenzen (git for-each-ref, git show-ref, git update-ref und git pack-refs) vereinheitlichen.
  • „git refs optimize“ – Optimierung des Backends zur Speicherung von Referenzen (analog zu „git pack-refs“).
  • „git refs list“ – Gibt eine Liste aller Referenzen aus (analog zu „git for-each-ref“ oder „git show-ref“).
  • „git refs exists“ – Überprüft die Existenz einer Referenz (entspricht „git show-ref —exists“).
• Das Format für den Export oder Import von Commit-Historien wurde um die Möglichkeit erweitert, mit kryptografischen Signaturen zu arbeiten, die sowohl auf SHA-1- als auch auf SHA-256-basierten Objekt-IDs basieren. Das Kommando „git fast-import“ unterstützt jetzt die Verarbeitung von signierten Tags analog zu signierten Commits. Es wurden die Optionen „—signed-commits=<Modus>“ und „—signed-tags=<Modus>“ hinzugefügt, um die Verarbeitung von signierten Commits und Tags während des Imports zu steuern (der Modus kann die Werte verbatim, warn-verbatim, warn-stri, strip oder abort annehmen).
• Im Befehl „git maintenance“ wurde eine neue Strategie „geometric“ hinzugefügt („git config set maintenance.strategy geometric“), die es ermöglicht, die Wartungszeit großer Monorepositories zu verkürzen. Im Vergleich zur zuvor verfügbaren Strategie, die die Logik des Befehls „git gc“ verwendet, vermeidet die neue Strategie die Neupackung aller Objekte und schließt ressourcenintensive Operationen wie das Zusammenführen aller Pack-Dateien aus (wenn möglich, wird die Zusammenführung schrittweise und ohne das Reinigen von entfernten Objekten durchgeführt).
• Das Kommando „git sparse-checkout clean“ wurde hinzugefügt, um die Wiederherstellung des Arbeitsverzeichnisses zu vereinfachen, indem Dateien entfernt werden, die nicht mit der neuen Definition des sparse-checkouts übereinstimmen und nicht in der lokalen Kopie gemäß den aktuellen sparse-checkout-Einstellungen vorhanden sein sollten.
• Um die Codebasis von Komplexität zu befreien und die Wartung zu vereinfachen, wurde ein Refactoring durchgeführt, um die Verwendung der globalen Variable the_repository zu reduzieren.
• Die Anwendung von Bloom-Filtern, einer probabilistischen Struktur zur Überprüfung des Vorhandenseins in einer Menge, wurde erweitert. Diese ermöglichen eine falsche Bestimmung fehlender Elemente, schließen jedoch das Übersehen vorhandener Elemente aus. Bloom-Filter werden jetzt verwendet, um die Suche in der Änderungshistorie zu beschleunigen, indem Wildcards in Dateipfaden angegeben werden, wie zum Beispiel „foo/bar/*/baz“.
• Die Performance des Befehls „git describe“ wurde um 30 % verbessert, dank der Nutzung einer Prioritätenwarteschlange. Die Umbenennung von Remote-Links in „git remote rename“ wurde beschleunigt. Die Anwendung von Indizes in „git ls-files“ wurde erweitert. Die Geschwindigkeit des Befehls „git log -L“ wurde deutlich erhöht, indem überflüssige dreistufige Vergleiche bei der Verarbeitung von Merge-Commits ausgeschlossen wurden. Optimierungen wurden in die xdiff-Bibliothek eingeführt.
• Es wurde die optionale Möglichkeit eingeführt, Implementierungen in der Programmiersprache Rust für einige interne Funktionen wie das Kodieren und Dekodieren von variablen ganzzahligen Werten zu verwenden. Standardmäßig wird der Rust-Code nicht verwendet, und um ihn zu aktivieren, muss das Build-Flag WITH_RUST angegeben werden. In Zukunft wird erwartet, dass eine Überarbeitung wichtiger interner Git-Komponenten in Rust erfolgt und Rust zu den erforderlichen Build-Abhängigkeiten in Git 3.0 hinzugefügt wird.
• Die Liste der inkompatiblen Änderungen, die in der Git-Version 3.0 angewendet werden, wurde aktualisiert. In Git 3.0 wurde beschlossen, die Standardkonfiguration für init.defaultBranch auf "main" zu ändern. Das bedeutet, dass in Repositories, die mit dem Befehl „git init“ erstellt werden, der Standardbranch "main" und nicht "master" genannt wird. Außerdem wird der Wechsel zum Standard-Hashalgorithmus SHA-256 für Objektnummern bei der Initialisierung neuer Repositories bemerkt. Um die Portabilität zwischen Repositories mit SHA-1 und SHA-256 Hash-IDs zu erleichtern, wurde die Möglichkeit geschaffen, in einem Repository mit einem Hashalgorithmus Push- und Pull-Operationen von einem Repository, das einen anderen Hashalgorithmus verwendet, durchzuführen.

Quelle: opennet.ru