Veröffentlichung des verteilten versionierten Systems Git 2.26

Verfügbar Veröffentlichung des verteilten versionierten Systems Git 2.26.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 504 Änderungen aufgenommen, die mit Unterstützung von 64 Entwicklern vorbereitet wurden, von denen 12 erstmals an der Entwicklung mitwirkten. Haupt Neuheiten:

• Der Standard wurde auf die zweite Version geändert des Kommunikationsprotokolls Git, das beim Remote-Zugriff des Clients auf den Git-Server verwendet wird. Die zweite Version des Protokolls ist bemerkenswert, da sie die Möglichkeit bietet, Branches und Tags auf der Serverseite zu filtern, was dem Client eine verkürzte Liste von Referenzen zurückgibt. Zuvor erhielt der Client bei der Ausführung eines Befehls zum Abrufen stets die vollständige Liste der Referenzen im gesamten Repository, selbst wenn er nur einen Branch aktualisierte oder die Aktualität seiner Repository-Kopie überprüfte. Eine weitere bemerkenswerte Neuerung ist die Möglichkeit, dem Protokoll neue Funktionen hinzuzufügen, sobald neue Funktionalitäten im Werkzeugkasten verfügbar sind. Der Client-Code bleibt mit dem alten Protokoll kompatibel und kann weiterhin sowohl mit neuen als auch mit alten Servern arbeiten, indem er automatisch auf die erste Version zurückgreift, falls der Server die zweite nicht unterstützt.
• Der Befehl „git config“ hat die Option „—show-scope“ hinzugefügt, die es erleichtert, den Ort zu identifizieren, an dem bestimmte Einstellungen definiert sind. Git ermöglicht die Definition von Einstellungen an verschiedenen Orten: im Repository (.git/info/config), im Benutzerverzeichnis (~/.gitconfig), in der systemweiten Konfigurationsdatei (/etc/gitconfig) sowie über Befehlszeilenoptionen und Umgebungsvariablen. Bei der Ausführung von „git config“ ist es ziemlich schwierig zu verstehen, wo genau die gesuchte Einstellung definiert ist. Um dieses Problem zu lösen, war die Option „—show-origin“ verfügbar, die lediglich den Pfad zur Datei anzeigt, in der die Einstellung definiert ist, was nützlich ist, wenn man die Datei bearbeiten möchte, jedoch nicht hilft, wenn man den Wert über „git config“ mit den Optionen „—system“, „—global“ oder „—local“ ändern möchte. Die neue Option „—show-scope“ zeigt den Kontext der Variablenbestimmung an und kann zusammen mit „—show-origin“ verwendet werden:

  $ git —list —show-scope —show-origin
  global file:/home/user/.gitconfig diff.interhunkcontext=1
  global file:/home/user/.gitconfig push.default=current
  […]
  local file:.git/config branch.master.remote=origin
  local file:.git/config branch.master.merge=refs/heads/master

  $ git config —show-scope —get-regexp ‘diff.*’
  global diff.statgraphwidth 35
  local diff.colormoved plain

  $ git config —global —unset diff.statgraphwidth

• In den Bindungseinstellungen Anmeldedaten Die Verwendung von Platzhaltern in URLs ist erlaubt. Alle Einstellungen für HTTP und Anmeldedaten in Git können sowohl für alle Verbindungen (http.extraHeader, credential.helper) als auch für URL-spezifische Verbindungen (credential.https://example.com.helper, credential.https://example.com.helper) festgelegt werden. Bisher war die Verwendung von Platzhaltern wie *.example.com nur für HTTP-Einstellungen zulässig, aber nicht für die Bindung von Anmeldedaten. In Git 2.26 wurden diese Unterschiede behoben, sodass beispielsweise zur Bindung eines Benutzernamens an alle Subdomains nun Folgendes angegeben werden kann:

  [credential «https://*.example.com»]

  username = ttaylorr

• Die experimentelle Unterstützung für partielle Klonierung (partial clones) wurde weiter ausgebaut, wodurch nur ein Teil der Daten übertragen und mit einer unvollständigen Kopie des Repositories gearbeitet werden kann. In dieser neuen Version wurde der Befehl "git sparse-checkout add" hinzugefügt, der es ermöglicht, einzelne Verzeichnisse für die Anwendung der "checkout"-Operation nur auf einen Teil des Arbeitsbaums hinzuzufügen, anstatt alle ähnlichen Verzeichnisse gleichzeitig über den Befehl "git sparse-checkout set" aufzulisten (es können Verzeichnisse einzeln hinzugefügt werden, ohne die gesamte Liste jedes Mal erneut angeben zu müssen).
  Zum Beispiel, um das Repository git/git zu klonen, ohne Blobs zu übertragen, die Überprüfung nur auf das Stammverzeichnis der Arbeitskopie zu beschränken und eine separate Kennzeichnung für das Abrufen der Verzeichnisse „t“ und „Documentation“ anzugeben, können Sie Folgendes verwenden:

  $ git clone —filter=blob:none —sparse git@github.com:git/git.git

  $ cd git
  $ git sparse-checkout init —cone

  $ git sparse-checkout add t
  ….
  $ git sparse-checkout add Documentation
  ….
  $ git sparse-checkout list
  Documentation
  t

• Die Leistung des Befehls „git grep“ wurde erheblich verbessert, wenn er sowohl im aktuellen Inhalt des Repositories als auch in historischen Revisionen zur Suche verwendet wird. Um die Suche zu beschleunigen, war es möglich, den Inhalt des Arbeitsverzeichnisses mit mehreren Threads zu scannen („git grep —threads“), jedoch war die Suche in historischen Revisionen einstufig. Diese Einschränkung wurde jetzt durch die Implementierung der Möglichkeit, Lesevorgänge aus dem Objektspeicher zu parallelisieren, aufgehoben. Standardmäßig wird die Anzahl der Threads auf die Anzahl der CPU-Kerne eingestellt, was in den meisten Fällen die explizite Angabe der Option „—threads“ überflüssig macht.
• Unterstützung für die automatische Vervollständigung von Subkommandos, Pfaden, Links und anderen Argumenten des Befehls „git worktree“ hinzugefügt, die das Arbeiten mit mehreren Arbeitskopien eines Repositories ermöglicht.
• Unterstützung für helle Farben hinzugefügt, die ANSI-Escape-Sequenzen unterstützen. Beispielsweise können in den Farbkonfigurationen „git config —color“ oder „git diff —color-moved“ über die Option „—format“ für hellblau „%C(brightblue)“ angegeben werden.
• Eine neue Version des Skripts hinzugefügt fsmonitor-watchman, die eine Integration mit dem Mechanismus Facebook Watchman zur Beschleunigung der Überwachung von Dateiänderungen und dem Erscheinen neuer Dateien gewährleistet. Nach dem Update von git ist es erforderlich, den Hook im Repository zu ersetzen. Optimierungen zur Beschleunigung von partiellen Klonvorgängen (partial clones) hinzugefügt, die mit der Anwendung von Bitmaps (bitmap machinery) verbunden sind, um eine vollständige Durchsuchung aller Objekte während der Ausgabe-Filterung zu vermeiden. Die Überprüfung von Blobs (—filter=blob:none und —filter=blob:limit=n) wird beim partiellen Klonen jetzt
• Optimierungen wurden hinzugefügt, um die Vorgänge des partiellen Klonens (partial clones) durch den Einsatz von Bitmaps zu beschleunigen.
  deutlich schneller durchgeführt. GitHub hat angekündigt, die Patches mit diesen Optimierungen und die experimentelle Unterstützung für partielle Klonvorgänge anzuwenden.
  Deutlich schneller. GitHub hat die Anwendung von Patches mit diesen Optimierungen und die experimentelle Unterstützung für das partielle Klonen angekündigt.
• Der Befehl „git rebase“ wurde auf eine andere Backend-Implementierung umgestellt, die standardmäßig die „merge“-Technik verwendet (früher für „rebase -i“ genutzt), anstelle von „patch+apply“. In einigen Aspekten unterscheiden sich die Backends; zum Beispiel bietet das neue Backend nach Fortsetzung der Operation nach der Behebung von Konflikten (git rebase --continue) die Möglichkeit, die Commit-Nachricht zu bearbeiten, während das alte einfach die vorherige Nachricht übernommen hat. Um das alte Verhalten wiederherzustellen, kann die Option „--apply“ verwendet oder die Konfigurationsvariable ‚rebase.backend‘ auf ‚apply‘ gesetzt werden.
• Ein Beispiel für einen Handler für Authentifizierungsparameter, die über .netrc definiert sind, wurde in eine sofort einsatzbereite Form gebracht.
• Die Einstellung gpg.minTrustLevel wurde hinzugefügt, um ein minimales Vertrauensniveau für verschiedene Elemente festzulegen, die digitale Signaturen überprüfen.
• Bei „git rm“ und „git stash“ wurde die Option „--pathspec-from-file“ hinzugefügt.
• Die Verbesserung der Test-Suites wurde fortgesetzt, um den Übergang zum SHA-2-Hashalgorithmus anstelle von SHA-1 vorzubereiten.

Quelle: opennet.ru