Veröffentlichung des verteilten Versionskontrollsystems Git 2.26

Verfügbar Veröffentlichung des verteilten Systems zur Verwaltung von Quelltexten Git 2.26.0Git ist eines der beliebtesten, zuverlässigsten und leistungsstärksten Versionskontrollsysteme, das flexible Mittel für die nichtlineare Entwicklung bietet, 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 das implizite Hashing der gesamten vorherigen Historie in jedem Commit verwendet; es ist auch möglich, einzelne Tags und Commits mit digitalen Signaturen der Entwickler zu authentifizieren.

Im Vergleich zur vorherigen Version wurden in die neue Version 504 Änderungen aufgenommen, die von 64 Entwicklern vorbereitet wurden, von denen 12 erstmals an der Entwicklung teilgenommen haben. Haupt- Neuheiten:

• Der Standardwechsel zu der zweiten Version des Git-Kommunikationsprotokolls wurde vollzogen, welches bei der Remote-Verbindung des Clients mit dem Git-Server verwendet wird. Die zweite Protokollversion ermöglicht es, Branches und Tags serverseitig zu filtern und dem Client lediglich eine verkürzte Liste von Referenzen zu übermitteln. Zuvor wurde bei der Ausführung eines beliebigen Fetch-Befehls dem Client immer die vollständige Liste der Referenzen im gesamten Repository gesendet, selbst wenn der Client nur einen Branch aktualisierte oder die Aktualität seiner Repository-Kopie prüfte. Eine weitere bemerkenswerte Neuerung ist die Möglichkeit, neue Funktionen in das Protokoll einzuführen, sobald neue Funktionalitäten in den Werkzeugen 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ückfällt, falls der Server die zweite nicht unterstützt.
• Im Befehl „git config“ wurde die Option „—show-scope“ hinzugefügt, die es erleichtert, den Ort zu ermitteln, an dem bestimmte Einstellungen definiert sind. Git erlaubt es, Einstellungen an verschiedenen Orten zu definieren: im Repository (.git/info/config), im Benutzerverzeichnis (~/ .gitconfig), in der globalen Konfigurationsdatei (/etc/gitconfig) sowie über Befehlszeilenoptionen und Umgebungsvariablen. Es ist oft schwierig zu verstehen, wo genau eine gesuchte Einstellung definiert ist. Um dieses Problem zu lösen, war zuvor die Option „—show-origin“ verfügbar, die jedoch nur 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 der Wert über „git config“ mit den Optionen „—system“, „—global“ oder „—local“ geändert werden soll. Die neue Option „—show-scope“ zeigt den Kontext der Variablen an und kann in Kombination 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 Bindingseinstellungen von Anmeldedaten Die Verwendung von Platzhaltern in URLs ist erlaubt. Alle HTTP-Einstellungen und Git-Anmeldeinformationen können sowohl für alle Verbindungen (http.extraHeader, credential.helper) als auch für Verbindungen, die an die URL gebunden sind (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, wurde jedoch nicht für die Bindung von Anmeldeinformationen unterstützt. In Git 2.26 wurden diese Unterschiede beseitigt, und beispielsweise kann zur Bindung eines Benutzernamens an alle Subdomains jetzt Folgendes angegeben werden:

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

  username = ttaylorr

• Die experimentelle Unterstützung für partielle Klone (partial clones) wird weiterhin ausgebaut, wodurch es möglich ist, nur einen Teil der Daten zu übertragen und mit einer unvollständigen Kopie des Repositories zu arbeiten. In der neuen Version wurde der neue Befehl „git sparse-checkout add“ hinzugefügt, mit dem einzelne Verzeichnisse zur Anwendung der „Checkout“-Operation nur auf einen Teil des Arbeitsbaums hinzugefügt werden können, anstatt alle ähnlichen Verzeichnisse auf einmal über den Befehl „git sparse-checkout set“ aufzulisten (Verzeichnisse können einzeln hinzugefügt werden, ohne die gesamte Liste jedes Mal erneut anzugeben).
  Zum Beispiel, um das Repository git/git zu klonen, ohne Blobs zu übertragen, die Überprüfung nur auf das Wurzelverzeichnis der Arbeitskopie zu beschränken und getrennte Markierungen für die Verzeichnisse „t“ und „Documentation“ zu ziehen, kann Folgendes angegeben werden:

  $ 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“, der sowohl im aktuellen Inhalt des Repositories als auch in historischen Revisionen verwendet wird, wurde erheblich verbessert. Um die Suche zu beschleunigen, war das Scannen des Inhalts des Arbeitsbaums mit mehreren Threads („git grep —threads“) zulässig, aber die Suche in historischen Revisionen war einstufig. Dieses Limit wurde nun durch die Implementierung der Möglichkeit, Leseoperationen aus dem Objektspeicher zu parallelisieren, aufgehoben. Standardmäßig wird die Anzahl der Threads auf die Anzahl der CPU-Kerne gesetzt, was in den meisten Fällen jetzt keine explizite Festlegung der Option „—threads“ erfordert.
• Die Unterstützung für die automatische Vervollständigung von Unterbefehlen, Pfaden, Links und anderen Argumenten des Befehls „git worktree“, der das Arbeiten mit mehreren Arbeitskopien eines Repositories ermöglicht, wurde hinzugefügt.
• Die Unterstützung für helle Farben wurde hinzugefügt, für die ANSI Escape-Sequenzen vorhanden sind. Zum Beispiel kann in den Farbeinstellungen der Hervorhebung „git config —color“ oder „git diff —color-moved“ über die Option „—format“ für hellblau „%C(brightblue)“ angegeben werden.
• Eine neue Version des Skripts wurde hinzugefügt. fsmonitor-watchman, das die Integration mit dem Mechanismus ermöglicht. Facebook Watchman zur Beschleunigung der Verfolgung von Dateiänderungen und dem Erscheinen neuer Dateien. Nach der Aktualisierung von Git wird benötigt: ersetzt werden kann ein Hook im Repository.
• Optimierungen zur Beschleunigung von Teilklonvorgängen (partial clones) wurden hinzugefügt, die mit der Anwendung von Bitmaps zusammenhängen,
  (Bitmap-Maschine), um eine vollständige Durchsuchung aller Objekte während der Antwortfilterung zu vermeiden. Die Prüfung auf Blobs (—filter=blob:none und —filter=blob:limit=n) erfolgt beim Teilklonen jetzt
  deutlich schneller. GitHub hat angekündigt, die Patches mit diesen Optimierungen und die experimentelle Unterstützung für Teilklonvorgänge anzuwenden.
• Der Befehl „git rebase“ wurde auf einen anderen Backend umgestellt, der standardmäßig den Mechanismus „merge“ verwendet (früher für „rebase -i“ benutzt) anstelle von „patch+apply“. In einigen Details unterscheiden sich die Backends, zum Beispiel schlägt das neue Backend nach der Fortsetzung des Vorgangs nach der Konfliktbehebung (git rebase —continue) vor, die Commit-Nachricht zu bearbeiten, während das alte einfach die alte Nachricht verwendet hat. Um das alte Verhalten wiederherzustellen, kann die Option „—apply“ verwendet oder die Konfigurationsvariable „rebase.backend“ auf den Wert „apply“ gesetzt werden.
• Ein Beispiel für einen Authentifizierungsparameter-Handler, der über .netrc festgelegt wurde, wurde in eine für den sofortigen Gebrauch geeignete Form gebracht.
• Die Einstellung gpg.minTrustLevel wurde hinzugefügt, um das minimale Vertrauensniveau für verschiedene Elemente festzulegen, die die digitale Signatur überprüfen.
• In „git rm“ und „git stash“ wurde die Option „—pathspec-from-file“ hinzugefügt.
• Die Verbesserung der Testsammlungen wird im Rahmen der Vorbereitung auf den Wechsel zu dem Hash-Algorithmus SHA-2 anstelle von SHA-1 fortgesetzt.

Quelle: opennet.ru