Veröffentlichung des verteilten Versionsverwaltungssystems Git 2.25

Verfügbar Veröffentlichung eines verteilten Versionsverwaltungssystems Git 2.25.0. Git ist eines der beliebtesten, zuverlässigsten und leistungsstärksten Versionskontrollsysteme und bietet flexible nichtlineare Entwicklungstools basierend auf Verzweigung und Zusammenführung. Um die Integrität des Verlaufs und die Widerstandsfähigkeit gegen rückwirkende Änderungen sicherzustellen, wird in jedem Commit ein implizites Hashing des gesamten vorherigen Verlaufs verwendet; es ist auch möglich, einzelne Tags und Commits mit digitalen Signaturen der Entwickler zu zertifizieren.

Im Vergleich zur Vorgängerversion enthielt die neue Version 583 Änderungen, die unter Beteiligung von 84 Entwicklern erstellt wurden, von denen 32 erstmals an der Entwicklung beteiligt waren. Haupt- Innovationen:

• Die Möglichkeit des teilweisen Klonens nähert sich der Stabilisierung und der vollständigen Bereitschaft, sodass Sie nur einen Teil der Daten übertragen und mit einer unvollständigen Kopie des Repositorys arbeiten können. Ein typischer Klon kopiert alle Daten aus dem Repository, einschließlich jeder Version jeder Datei im Änderungsverlauf. Bei sehr großen Repositorys führt das Kopieren von Daten zu einem erheblichen Anstieg des Datenverkehrs und des Speicherplatzes, selbst wenn der Entwickler nur an einer Teilmenge der Dateien interessiert ist. Um es einfacher zu machen, nur einen Teil des funktionierenden Quellbaums abzurufen, führt die neue Version einen experimentellen „sparse-checkout“-Befehl und eine neue „--sparse“-Option für den „clone“-Befehl ein.

  Zuvor wurde der selektive Klonvorgang über die Aufgabe durchgeführt Filter um unnötigen Inhalt herauszufiltern und die Option „—no-checkout“, um das Ausfüllen fehlender Dateien zu deaktivieren. Danach musste vor dem Ausführen des Checkout-Vorgangs die Einstellung core.sparseCheckout aktiviert und eine Liste ausgeschlossener Pfadmuster in der Datei .git/info/sparse-checkout definiert werden. Um beispielsweise ohne Blobs zu klonen und zu verhindern, dass Dateien aus Unterverzeichnissen der Tiefe 2 oder mehr extrahiert werden, können Sie 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 der Arbeit mit einem unvollständigen Repository auf die folgenden Befehle:

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

  Mit dem Befehl sparse-checkout können Sie eine Liste von Pfaden zum Auschecken festlegen (set), ohne .git/info/sparse-checkout manuell zu konfigurieren, sowie die aktuelle Liste von Pfaden anzeigen (list) und teilweise Auschecken aktivieren oder deaktivieren (enable /deaktivieren).

  Um die Arbeit mit sehr großen Repositories und Vorlagenlisten zu optimieren, ist „git config core.sparseCheckoutCone", wodurch zulässige Muster eingeschränkt werden (anstelle beliebiger .gitignore-Muster können Sie angeben, ob alle Pfade und alle Dateien in einem bestimmten Unterverzeichnis ausgecheckt werden sollen). Wenn ein großes Repository beispielsweise ein Verzeichnis „A/B/C“ hat und die gesamte Arbeit im Unterverzeichnis „C“ konzentriert ist, wird beim Aktivieren des sparseCheckoutCone-Modus der Befehl „git sparse-checkout set A/B/“ angezeigt. „C“ extrahiert den gesamten Inhalt von „C“, aber aus „A“ und „B“ extrahiert es nur die Teile, die für die Arbeit mit „C“ erforderlich sind.

• Aus der Dokumentation („git rebase -h“) wurden alle Verweise auf die Option „--preserve-merges“ entfernt, die veraltet ist und stattdessen zum Migrieren einer Reihe von Commits verwendet werden sollte.git rebase --rebase-merges«.
• Um die Lesbarkeit von Nachrichten mit Patches zu verbessern, die an Mailinglisten gesendet werden, wurde die Option „git format-patch —cover-from-description subject“ hinzugefügt. Wenn angegeben, wird der erste Absatz aus dem Branch-Beschreibungstext als Betreff der verwendet Anschreiben für einen Satz Patches.
• Unterstützung für die kombinierte Verwendung des Befehls „git apply -3way“ und der Einstellung „merge.conflictStyle“ implementiert („git apply“ berücksichtigt jetzt den Konfliktbeschreibungsstil von merge.conflictStyle, wenn der Konflikt nach einem Versuch gelöst werden muss um eine Patch-Datei auf das Repository anzuwenden).
• Der Funktionsdefinitionscode, der in Operationen wie „git diff/grep --show-function/-function-context“ verwendet wird, wurde erweitert, um die Definition von Funktionsgrenzen in Sprachprogrammen zu unterstützen Elixier.
• Zu „git add“, „git commit“, „git reset“ und anderen Befehlen wurde eine neue Option hinzugefügt – „-pathspec-from-file“, die es ermöglicht, eine Liste von Pfaden aus einer Datei oder einem Eingabestream zu laden , anstatt sie in der Befehlszeile aufzulisten.
• Das Problem mit der Erkennung von Umbenennungen auf Verzeichnisebene beim Schreiben von Commits wurde behoben. Die Definition funktionierte nicht, wenn der Inhalt eines Unterverzeichnisses in das Stammverzeichnis des Repositorys verschoben wurde.
• Es wurde eine erste Implementierung des neu gestalteten Befehls „git add -i“ vorgeschlagen, der es Ihnen ermöglicht, geänderte Inhalte interaktiv hinzuzufügen, neu geschrieben von Perl nach C. Eine ähnliche Überarbeitung des Befehls „git add -p“ ist im Gange.
• Der Befehl „git log –graph“ wurde überarbeitet und generiert ein ASCII-Bild eines Diagramms mit dem Änderungsverlauf im Repository. Durch die Überarbeitung konnte die Ausgabe deutlich verbessert und vereinfacht werden, ohne die Struktur der Geschichte zu verzerren, wodurch beispielsweise das Problem gelöst wurde, dass das Bild über die Endzeilenbreite hinausragte.
• Mit der Option „git log --format=..“ können Sie das Ausgabeformat ändern.
  erweitert um Unterstützung für die „l/L“-Flags, um nur den Teil der E-Mail-Adresse anzuzeigen, der vor dem „@“-Symbol angegeben ist (z. B. nützlich, wenn alle Entwickler alle E-Mails in derselben Domäne haben).

• Dem Befehl „git submodule“ wurde ein Unterbefehl „set-url“ hinzugefügt.
• Die Testkits wurden in Vorbereitung auf den Übergang aktualisiert
  Hashing-Algorithmus SHA-2 statt SHA-1.

Source: opennet.ru