Veröffentlichung des verteilten Versionskontrollsystems Git 2.25

Verfügbar Veröffentlichung des verteilten versionierten Systems Git 2.25.0. Git gehört zu den beliebtesten, zuverlässigen und leistungsstärksten Versionsverwaltungssystemen und bietet flexible Mittel für nicht-lineare Entwicklungen, die auf dem Branching und Merging von Zweigen basieren. Um die Integrität der Historie und die Widerstandsfähigkeit gegenüber nachträglichen Änderungen zu gewährleisten, werden alle vorherigen Historien in jedem Commit implizit gehasht, und es ist auch möglich, digitale Signaturen für bestimmte Tags und Commits der Entwickler zu verwenden.

Im Vergleich zur vorherigen Version wurden in die neue Version 583 Änderungen integriert, an denen 84 Entwickler beteiligt waren, von denen 32 erstmals an der Entwicklung mitwirkten. Haupt Neuheiten:

• Die Möglichkeit des teilweisen Klonens nähert sich der Stabilität und vollständigen Bereitstellung. Diese Funktion ermöglicht es, nur einen Teil der Daten zu übertragen und mit einer unvollständigen Kopie des Repositories zu arbeiten. Bei einem normalen Klonen werden alle Daten, einschließlich jeder Version jeder Datei aus der Änderungshistorie, kopiert. Bei sehr großen Repositories kann das Kopieren von Daten zu einem erheblichen Anstieg des Datenverkehrs und des Speicherplatzbedarfs führen, selbst wenn der Entwickler nur an einer Teilmenge von Dateien interessiert ist. Um die Beschaffung eines Teils des Arbeitsverzeichnisses der Quelltexte zu erleichtern, wurde in dieser neuen Version der experimentelle Befehl „sparse-checkout“ und eine neue Option „—sparse“ für den Befehl „clone“ eingeführt.

  Zuvor wurde der Vorgang des selektiven Klonens über die Angabe von Filtern um überflüssige Inhalte auszuschließen und die Option «—no-checkout» zu nutzen, um das Auffüllen fehlender Dateien zu deaktivieren. Danach musste vor der Ausführung des Checkout-Vorgangs die Einstellung core.sparseCheckout aktiviert und in der Datei .git/info/sparse-checkout eine Liste der auszuschließenden Pfadmuster definiert werden. Zum Beispiel konnte man für ein Klonen ohne Blobs und das Verhindern des Auspackens von Dateien aus verschachtelten Verzeichnissen mit einer Tiefe von 2 oder mehr Folgendes ausführen:

  git clone —filter=blob:none —no-checkout /your/repository/here repo
  $ cd repo
  $ cat >.git/info/sparse-checkout <EOF
  /*
  !/*
  EOF
  $ git config core.sparseCheckout 1
  $ git checkout .

  Der neue Befehl «git sparse-checkout» vereinfacht die Arbeit erheblich und reduziert den Prozess der Organisation des Arbeitens mit unvollständigen Repositories auf folgende Befehle:

  git clone —filter=blob:none —sparse /your/repository/here repo
  git sparse-checkout set /path/to/check/out

  Der sparse-checkout-Befehl ermöglicht das Festlegen einer Liste von Pfaden für den Checkout (set), ohne manuelle Anpassung der .git/info/sparse-checkout vorzunehmen, sowie das Anzeigen der aktuellen Pfadliste (list) und das Aktivieren oder Deaktivieren von partiellen Checkouts (enable/disable).

  Um die Arbeit mit sehr großen Repositories und Listen von Mustern zu optimieren, wurde die Einstellung «git config core.sparseCheckoutCone«, die zulässige Vorlagen einschränkt (anstatt beliebiger .gitignore-Vorlagen können alle Pfade und alle Dateien in einem bestimmten Unterverzeichnis festgelegt werden, die extrahiert werden sollen). Wenn es in einem großen Repository beispielsweise ein Verzeichnis „A/B/C“ gibt und die gesamte Arbeit sich im Unterverzeichnis „C“ konzentriert, extrahiert der Befehl „git sparse-checkout set A/B/C“ im Sparse-Checkout-Modus den Inhalt von „C“ vollständig, bei „A“ und „B“ jedoch nur die Teile, die für die Arbeit mit „C“ erforderlich sind.

• Aus der Dokumentation („git rebase -h“) wurden alle Erwähnungen der Option „—preserve-merges“ entfernt, die als veraltet gilt. Stattdessen sollte „git rebase —rebase-merges«.
• Um die Lesbarkeit der Nachrichten mit Patches, die an Mailing-Listen gesendet werden, zu verbessern, wurde die Option „git format-patch —cover-from-description subject“ hinzugefügt. Bei Angabe dieser Option wird der erste Absatz des Beschreibungstextes der Branch als Betreff für das Begleitschreiben der Patch-Sätze verwendet.
• Die Unterstützung für den gemeinsamen Einsatz des Befehls „git apply —3way“ und der Einstellung „merge.conflictStyle“ wurde implementiert. Nun berücksichtigt „git apply“ den Konfliktbeschreibungstil aus merge.conflictStyle, wenn es notwendig ist, Konflikte nach dem Versuch, eine Patch-Datei auf das Repository anzuwenden, zu lösen.
• Der Code zur Bestimmung von Funktionen, der in Operationen wie „git diff/grep —show-function/—function-context“ verwendet wird, wurde um die Unterstützung zur Bestimmung der Funktionsgrenzen in Programmen in der Sprache Elixir.
• In „git add“, „git commit“, „git reset“ und andere Befehle wurde eine neue Option „—pathspec-from-file“ hinzugefügt, die es ermöglicht, eine Liste von Pfaden aus einer Datei oder einem Eingabestrom zu laden, anstatt sie in der Befehlszeile aufzulisten.
• Ein Problem bei der Erkennung von Umbenennungen auf Verzeichnisebene beim Aufzeichnen von Commits wurde behoben. Die Erkennung funktionierte nicht, wenn der Inhalt eines Unterverzeichnisses in das Wurzelverzeichnis des Repositories verschoben wurde.
• Es wurde eine erste Implementierung des überarbeiteten Befehls „git add -i“ vorgeschlagen, die es ermöglicht, geänderte Inhalte interaktiv hinzuzufügen und von Perl nach C umgeschrieben wurde. Eine ähnliche Überarbeitung des Befehls „git add -p“ ist im Gange.
• Das Kommando „git log —graph“, das eine ASCII-Darstellung des Änderungsverlaufs im Repository erstellt, wurde überarbeitet. Die Neugestaltung ermöglicht eine erhebliche Verbesserung und Vereinfachung der Ausgabe, ohne die Struktur der Historie zu verzerren, was beispielsweise das Problem des Überlaufens der Grafik über die Zeilenbreite des Terminals gelöst hat.
• Die Option „git log —format=..“, die das Ausgabeformat ändern kann,
  wurde um die Unterstützung der Flags „l/L“ erweitert, um nur den Teil der E-Mail-Adresse auszugeben, der vor dem Zeichen „@“ angegeben ist (z. B. nützlich, wenn alle Entwickler ihre E-Mails in einer Domäne haben).
• Der Befehl „git submodule“ hat den Unterbefehl „set-url“ erhalten.
• Die Test-Suites wurden aktualisiert im Rahmen der Vorbereitung auf
  den Wechsel zum Hash-Algorithmus SHA-2 anstelle von SHA-1.

Quelle: opennet.ru