Version des Quellcodeverwaltungssystems Git 2.52.

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

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

• Der Befehl „git last-modified“ wurde hinzugefügt, um eine Liste der Dateien in der angegebenen Revision und der Commits anzuzeigen, durch die die letzten Änderungen an jeder dieser Dateien vorgenommen wurden. $ git last-modified HEAD b56f6dcd7b4c90192018e848d0810f091d092913 test.h 29330ae4b820147c98e723399e9438c8bee60a8a test1.c 573ad8917beb99dc643b6e7f5c117a294384a575 test2.c
• Der Befehl „git repo“ wurde hinzugefügt, um Aktionen im Zusammenhang mit dem Abrufen von Informationen aus dem Repository durchzuführen. Es wurden zwei Unterbefehle vorgeschlagen — „git repo info“ und „git repo structure“, die Informationen zu den Repository-Einstellungen und zur Struktur des Repositories ausgeben (z. B. kann die Anzahl der Referenzen und Objekte im Repository abgefragt werden). $ 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 | | * Andere | 0 | | | | | * Erreichbare Objekte | | | * Anzahl | 518955 | | * Commits | 77469 | | * Bäume | 188865 | | * Blobs | 251631 | | * Tags | 990 |
• In den Befehl „git refs“ wurden drei Unterbefehle integriert, die die verschiedenen und überlappenden Low-Level-Operationen an 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“ — Ausgabe einer Liste aller Referenzen (analog zu „git for-each-ref“ oder „git show-ref“).
  • „git refs exists“ — Überprüfung der Existenz einer Referenz (analog zu „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-basierenden Objekt-IDs beruhen. In den Befehl „git fast-import“ wurde die Unterstützung für die Verarbeitung von signierten Tags analog zu signierten Commits implementiert. 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).
• Der Befehl „git maintenance“ hat Unterstützung für die neue Strategie „geometric“ („git config set maintenance.strategy geometric“) erhalten, die die Wartungszeit großer Monorepositories verkürzt. Im Vergleich zur vorher verfügbaren Strategie, die die Logik des Befehls „git gc“ verwendet, vermeidet die neue Strategie das Neu-Packen aller Objekte und schließt übermäßig ressourcenintensive Operationen aus, wie das Zusammenführen aller Pack-Dateien (wenn möglich, wird die Zusammenführung in Teilen und ohne Bereinigung entfernter Objekte durchgeführt).
• Der Befehl „git sparse-checkout clean“ wurde hinzugefügt, um die Wiederherstellung des Arbeitsverzeichnisses zu erleichtern, indem Dateien entfernt werden, die nicht der neuen Definition des Sparse-Checkout entsprechen und die in der lokalen Kopie gemäß den aktuellen Sparse-Checkout-Einstellungen nicht vorhanden sein sollten.
• Um die Codebasis von Komplexitäten zu befreien und die Wartung zu erleichtern, wurde ein Refactoring durchgeführt, um die Verwendung der globalen Variablen the_repository zu reduzieren.
• Die Anwendung von Bloom-Filtern, einer probabilistischen Struktur zur Überprüfung von Memberships in Mengen, wurde erweitert, die eine falsche Bestimmung eines fehlenden Elements zulässt, jedoch das Übersehen eines vorhandenen Elements ausschließt. Bloom-Filter werden jetzt verwendet, um die Suche in der Änderungshistorie zu beschleunigen, wenn Masken in Dateipfaden angegeben werden, beispielsweise „foo/bar/*/baz“.
• Die Leistung des Befehls „git describe“ wurde um 30 % verbessert, durch die Verwendung einer Prioritätswarteschlange. In „git remote rename“ wurden die Umbenennungsoperationen beschleunigt. In „git ls-files“ wurde die Anwendung der Indizes erweitert. Die Verarbeitung des Befehls „git log -L“ hat sich merklich beschleunigt, da überflüssige dreistufige Vergleiche bei der Verarbeitung von Merge-Commits ausgeschlossen wurden. Es wurden Optimierungen in der Bibliothek xdiff vorgenommen.
• Es wurde die optionale Möglichkeit bereitgestellt, Implementierungen bestimmter interner Funktionen in der Programmiersprache Rust zu verwenden, wie z.B. das Codieren und Dekodieren von ganzzahligen Werten variabler Länge. Standardmäßig wird kein Rust-Code verwendet, und um ihn zu aktivieren, muss das Build-Flag WITH_RUST angegeben werden. In Zukunft wird erwartet, dass bedeutendere interne Komponenten von Git auf Rust umgestellt werden, und dass Rust zu den verpflichtenden Build-Abhängigkeiten in Git 3.0 gehört.
• Die Liste der inkompatiblen Änderungen, die in der Git 3.0-Version angewendet werden, wurde aktualisiert. In Git 3.0 wurde beschlossen, die Standardkonfiguration für init.defaultBranch auf „main“ zu ändern, d.h. in Repositories, die mit dem Kommando „git init“ erstellt werden, wird der Standardbranch „main“ und nicht „master“ genannt. Es wird auch auf die Standardumstellung auf Objekt-IDs basierend auf dem SHA-256-Hash-Algorithmus hingewiesen, wenn neue Repositories initialisiert werden. Um die Portabilität zwischen Repositories mit SHA-1- und SHA-256-Hash-basierten Objekt-IDs zu erleichtern, wird die Möglichkeit bereitgestellt, in einem Repository mit einem Hash-Algorithmus Push- und Pull-Operationen aus einem Repository, das einen anderen Hash-Algorithmus verwendet, durchzuführen.

Quelle: opennet.ru