{"id":103093,"date":"2022-01-25T15:36:40","date_gmt":"2022-01-25T13:36:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-35"},"modified":"2022-01-25T15:36:40","modified_gmt":"2022-01-25T13:36:40","slug":"vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-35","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-35","title":{"rendered":"Die Ver\u00f6ffentlichung des Quellcode-Management-Systems Git 2.35.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nach zwei Monaten Entwicklung wurde die Version 2.35 des verteilten Systems zur Verwaltung von Quelltexten Git ver\u00f6ffentlicht. Git ist eines der beliebtesten, zuverl\u00e4ssigsten und leistungsst\u00e4rksten Versionsverwaltungssysteme, das flexible Werkzeuge f\u00fcr die nichtlineare Entwicklung auf Basis von Branching und Merging bietet. Um die Integrit\u00e4t der Historie und die Widerstandsf\u00e4higkeit gegen \u00c4nderungen «r\u00fcckblickend» zu gew\u00e4hrleisten, wird das gesamte vorherige History implizit in jedem Commit gehasht; auch die digitale Signatur von Entwicklern f\u00fcr einzelne Tags und Commits ist m\u00f6glich. <\/p>\n
Im Vergleich zur vorherigen Version wurden 494 \u00c4nderungen \u00fcbernommen, die von 93 Entwicklern vorbereitet wurden, darunter 35, die zum ersten Mal an der Entwicklung teilgenommen haben. Zu den Hauptneuheiten geh\u00f6ren: <\/p>\n
\n
Die Funktionen zur Verwendung von SSH-Schl\u00fcsseln zur digitalen Signierung von Git-Objekten wurden erweitert. Um die G\u00fcltigkeitsdauer mehrerer Schl\u00fcssel zu differenzieren, wurde die Unterst\u00fctzung f\u00fcr OpenSSH-Direktiven «valid-before» und «valid-after» hinzugef\u00fcgt, die eine korrekte Handhabung der Signaturen nach der Rotation eines der Schl\u00fcssel von Entwicklern erm\u00f6glichen. Zuvor gab es das Problem der Trennung von Signaturen mit alten und neuen Schl\u00fcsseln \u2014 wenn der alte Schl\u00fcssel gel\u00f6scht wurde, konnte man die damit erstellten Signaturen nicht mehr \u00fcberpr\u00fcfen, und wenn er beibehalten wurde, bestand die M\u00f6glichkeit, neue Signaturen mit dem alten Schl\u00fcssel zu erstellen, obwohl bereits ein neuer Schl\u00fcssel vorhanden war. Mit valid-before und valid-after k\u00f6nnen die G\u00fcltigkeitsbereiche der Schl\u00fcssel basierend auf dem Erstellungsdatum der Signatur getrennt werden.\n
In der Einstellung merge.conflictStyle, die es erm\u00f6glicht, den Modus der Konfliktinformation beim Mergen auszuw\u00e4hlen, wurde die Unterst\u00fctzung f\u00fcr den Modus «zdiff3» hinzugef\u00fcgt, der alle g\u00e4ngigen Zeilen, die am Anfang oder Ende des Konflikts angegeben sind, au\u00dferhalb des Konfliktbereichs verschiebt, was eine kompaktere Darstellung der Informationen erm\u00f6glicht.\n
Der Befehl «git stash» hat den Modus «--staged» hinzugef\u00fcgt, der es erlaubt, nur \u00c4nderungen zu verbergen, die zum Index hinzugef\u00fcgt wurden, etwa in Situationen, in denen es notwendig ist, einen Teil komplexer \u00c4nderungen vor\u00fcbergehend zur\u00fcckzustellen, um zun\u00e4chst das hinzuzuf\u00fcgen, was bereits fertig ist, und sich sp\u00e4ter um den Rest zu k\u00fcmmern. Dieser Modus \u00e4hnelt dem Befehl «git commit», der nur die ins Index aufgenommenen \u00c4nderungen speichert, aber anstelle eines neuen Commits werden die Ergebnisse in den tempor\u00e4ren Stash von «git stash --staged» gespeichert. Sobald die \u00c4nderungen ben\u00f6tigt werden, k\u00f6nnen sie mit dem Befehl «git stash pop» wiederhergestellt werden.\n
Der Befehl «git log» hat einen neuen Format-Spezifizierer «--format=%(describe)» hinzugef\u00fcgt, der eine Kombination der Ausgabe von «git log» mit dem Ergebnis des Befehls «git describe» erm\u00f6glicht. Die Parameter f\u00fcr «git describe» werden direkt innerhalb des Spezifizierers angegeben («--format=%(describe:match=,exclude=)»), wobei auch verk\u00fcrzte Tags («--format=%(describe:tags=)») und die Anzahl der hexadezimalen Zeichen zur Identifizierung von Objekten («--format=%(describe:abbrev=)») angepasst werden k\u00f6nnen. Zum Beispiel kann man den Befehl verwenden, um die letzten 8 Commits anzuzeigen, deren Tags kein Release-Kandidaten-Tag haben, und 8-stellige Identifikatoren anzugeben: $ git log -8 --format='%(describe:exclude=*-rc*,abbrev=13)' v2.34.1-646-gaf4e5f569bc89 v2.34.1-644-g0330edb239c24 v2.33.1-641-g15f002812f858 v2.34.1-643-g2b95d94b056ab v2.34.1-642-gb56bd95bbc8f7 v2.34.1-203-gffb9f2980902d v2.34.1-640-gdf3c41adeb212 v2.34.1-639-g36b65715a4132\n
In der Einstellung user.signingKey wurde die Unterst\u00fctzung f\u00fcr neue Schl\u00fcsseltypen implementiert, die nicht auf den Typ «ssh-» beschr\u00e4nkt sind und den vollst\u00e4ndigen Dateipfad zum Schl\u00fcssel angeben. Alternative Typen werden mit dem Pr\u00e4fix «key::» angegeben, z. B. «key::ecdsa-sha2-nistp256» f\u00fcr ECDSA-Schl\u00fcssel.\n
Die Geschwindigkeit der Generierung der \u00c4nderungs\u00fcbersicht im Modus «--histogram» sowie bei Verwendung der Option «--color-moved-ws», die die Hervorhebung von Leerzeichen im farbigen Diff steuert, wurde deutlich erh\u00f6ht.\n
Im Befehl «git jump», der verwendet wird, um Vim Informationen \u00fcber pr\u00e4zise \u00dcberg\u00e4nge zur angestrebten Position in der Datei beim L\u00f6sen von Merge-Konflikten, Vergleichen von Differenzen oder Ausf\u00fchren von Suchoperationen zu geben, wurde die M\u00f6glichkeit eingef\u00fchrt, den Anwendungsbereich der Merge-Konflikte einzuschr\u00e4nken. Beispielsweise kann man f\u00fcr die Einschr\u00e4nkung der Operationen auf das Verzeichnis «foo» den Befehl «git jump merge -- foo» verwenden, und um das Verzeichnis «Documentation» von der Bearbeitung auszuschlie\u00dfen \u2014 «git jump merge -- ':^Documentation'».\n
Es wurde daran gearbeitet, den Typ «size_t» anstelle von «unsigned long» f\u00fcr Werte zu standardisieren, die die Gr\u00f6\u00dfe von Objekten repr\u00e4sentieren, was die Anwendung der Filter «clean» und «smudge» auf Dateien gr\u00f6\u00dfer als 4 GB auf allen Plattformen, einschlie\u00dflich Plattformen mit dem LLP64-Datenmodell, das den Typ «unsigned long» auf 4 Byte beschr\u00e4nkt, erm\u00f6glicht.\n
Der Befehl «git am» erhielt die Option «—empty=(stop|drop|keep)», die es erm\u00f6glicht, beim Parsen von Patches aus dem Posteingang das Verhalten f\u00fcr leere E-Mails, die keine Patches enthalten, auszuw\u00e4hlen. Der Wert «stop» beendet den gesamten Patch-Anwendungsprozess, «drop» \u00fcberspringt den leeren Patch, und «keep» erstellt einen leeren Commit.\n
Die Befehle «git reset», «git diff», «git blame», «git fetch», «git pull» und «git ls-files» unterst\u00fctzen jetzt partielle Indizes (sparse index), die die Leistung verbessern und Speicherplatz in Repositories sparen, in denen partielle Klonvorg\u00e4nge (sparse-checkout) durchgef\u00fchrt werden.\n
Der Befehl «git sparse-checkout init» wurde als veraltet erkl\u00e4rt. Stattdessen sollte der Befehl «git sparse-checkout set» verwendet werden.\n
Eine erste Implementierung des neuen Backends «reftable» zum Speichern von Referenzen wie Branches und Tags im Repository wurde hinzugef\u00fcgt. Das neue Backend nutzt ein Blockspeicher, das f\u00fcr das Projekt JGit entwickelt wurde und f\u00fcr die Speicherung einer sehr gro\u00dfen Anzahl von Referenzen optimiert ist. Das Backend ist noch nicht in das Referenzsystem integriert und ist noch nicht f\u00fcr den praktischen Einsatz bereit.\n
Die Farbpalette des Befehls «git grep» wurde an das GNU grep Werkzeug angepasst. <\/ul>\n