{"id":108813,"date":"2023-06-02T15:10:15","date_gmt":"2023-06-02T13:10:16","guid":{"rendered":"https:\/\/prohoster.info\/?p=108813"},"modified":"2023-06-02T17:30:17","modified_gmt":"2023-06-02T15:30:17","slug":"dostupna-sistema-upravleniya-ishodnymi-tekstami-git-2-41","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/dostupna-sistema-upravleniya-ishodnymi-tekstami-git-2-41","title":{"rendered":"Das Versionsverwaltungssystem Git 2.41 ist verf\u00fcgbar","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nach drei Monaten Entwicklung wurde die Version 2.41 des verteilten Quelltextverwaltungssystems Git ver\u00f6ffentlicht. Git ist eines der beliebtesten, zuverl\u00e4ssigsten und leistungsst\u00e4rksten Versionskontrollsysteme, das flexible Mittel f\u00fcr nichtlineare Entwicklungen bietet, die auf Verzweigungen und Merging von Branches basieren. Um die Integrit\u00e4t der Historie und die Widerstandsf\u00e4higkeit gegen \u00c4nderungen 'nachtr\u00e4glich' zu gew\u00e4hrleisten, wird implizites Hashing der gesamten vorherigen Historie in jedem Commit verwendet. Zudem ist die Best\u00e4tigung durch digitale Signaturen der Entwickler f\u00fcr einzelne Tags und Commits m\u00f6glich. <\/p>\n
Im Vergleich zur vorherigen Version wurden in die neue Version 542 \u00c4nderungen aufgenommen, die von 95 Entwicklern vorbereitet wurden, von denen 29 erstmals an der Entwicklung beteiligt waren. Zu den wichtigsten Neuerungen z\u00e4hlen: <\/p>\n
\n
Die Verarbeitung von nicht erreichbaren Objekten (unreachable), auf die im Repository keine Verweise existieren (keine Referenzen durch Branches oder Tags), wurde verbessert. Nicht erreichbare Objekte werden vom Garbage Collector entfernt, verbleiben jedoch f\u00fcr eine gewisse Zeit im Repository, um Rennbedingungen auszuschlie\u00dfen. Um den Zeitraum, in dem nicht erreichbare Objekte vorhanden sind, zu verfolgen, m\u00fcssen sie mit Zeitstempeln versehen werden, was es nicht erlaubt, sie in einer einzigen Packdatei zu speichern, in der alle Objekte eine gemeinsame \u00c4nderungszeit haben. Fr\u00fcher wurde jedes nicht erreichbare Objekt in einer separaten Datei gespeichert, was bei einer gro\u00dfen Anzahl von neuen nicht erreichbaren Objekten, die noch nicht zum L\u00f6schen f\u00e4llig sind, zu Problemen f\u00fchrte. In der neuen Version wird f\u00fcr die Packung nicht erreichbarer Objekte standardm\u00e4\u00dfig der Mechanismus der \u201ecruft packs\u201c verwendet, der es erm\u00f6glicht, alle nicht erreichbaren Objekte in einer einzigen Packdatei zu speichern, w\u00e4hrend die \u00c4nderungsdaten jedes Objekts in einer separaten Tabelle erfasst werden, die in einer Datei mit der Erweiterung \u201e.mtimes\u201c gespeichert und \u00fcber eine Indexdatei mit der Erweiterung \u201e.idx\u201c verkn\u00fcpft wird.
<\/center>\n
Die diskbasierte R\u00fcckindexierung (revindex) f\u00fcr Pack-Dateien ist standardm\u00e4\u00dfig aktiviert. Bei Tests mit dem Repository torvalds\/linux erm\u00f6glichte die Anwendung des R\u00fcckindexes eine Beschleunigung ressourcenintensiver Operationen wie 'git push' um das 1,49-fache, w\u00e4hrend einfache Operationen, wie die Berechnung der Gr\u00f6\u00dfe eines Objekts mit 'git cat-file --batch='%(objectsize:disk)', um das 77-fache schneller waren. Dateien ('.rev') mit R\u00fcckindex werden im Repository im Verzeichnis '.git\/objects\/pack' gespeichert.\n
Zur Erinnerung: Git speichert alle Daten in Form von Objekten, die in separaten Dateien abgelegt sind. Um die Effizienz der Arbeit mit dem Repository zu erh\u00f6hen, werden die Objekte zus\u00e4tzlich in Pack-Dateien gespeichert, in denen die Informationen als Strom von aufeinanderfolgenden Objekten dargestellt sind (ein \u00e4hnliches Format wird beim \u00dcbertragen von Objekten mit den Befehlen git fetch und git push verwendet). F\u00fcr jede Pack-Datei wird eine Indexdatei (.idx) erstellt, die es erm\u00f6glicht, den Offset im Pack-Datei anhand der Objekt-ID sehr schnell zu bestimmen, an dem dieses Objekt gespeichert ist. <\/p>\n
Der im neuen Release enthaltene R\u00fcckindex zielt darauf ab, den Prozess der Identifizierung von Objekten basierend auf den Speicherinformationen im Pack-Datei zu optimieren. Fr\u00fcher wurde eine solche Umwandlung zur Laufzeit beim Parsen der Pack-Datei durchgef\u00fchrt und nur im Speicher gehalten, was eine Wiederverwendung solcher Indizes verhinderte und die Generierung des Indexes jedes Mal erforderlich machte. Der Indexierungsprozess reduziert sich auf den Aufbau eines Arrays von 'Objekt-Position'-Paaren und dessen Sortierung nach Position, was bei gro\u00dfen Pack-Dateien viel Zeit in Anspruch nehmen kann. <\/p>\n
Zum Beispiel wurde die Operation zur Ausgabe des Inhalts von Objekten, bei der ein direkter Index verwendet wird, 62-mal schneller ausgef\u00fchrt als die Operation zur Anzeige der Gr\u00f6\u00dfe von Objekten, bei der die Positionsverkn\u00fcpfungsdaten nicht indiziert wurden. Nach der Verwendung des umgekehrten Index ben\u00f6tigten die angegebenen Operationen ungef\u00e4hr die gleiche Zeit. Umgekehrte Indizes erm\u00f6glichen auch eine Beschleunigung der Objekt\u00fcbertragungsoperationen bei Ausf\u00fchrungen von Fetch- und Push-Befehlen, indem bereits vorbereitete Daten direkt von der Festplatte \u00fcbertragen werden.
<\/center> <\/p>\n
Im Protokoll «credential helper», das zur \u00dcbertragung von Anmeldeinformationen bei Zugriff auf Repositories mit eingeschr\u00e4nktem Zugang verwendet wird, wurde die Unterst\u00fctzung f\u00fcr die \u00dcbertragung von WWW-Authenticate-Headern zwischen dem Anmeldeinformations-Handler und dem Dienst, in dem die Authentifizierung erfolgt, hinzugef\u00fcgt. Die Unterst\u00fctzung des WWW-Authenticate-Headers erm\u00f6glicht die \u00dcbertragung von OAuth-Scope-Parametern f\u00fcr eine differenziertere Zugriffskontrolle auf Repositories und eine genauere Abgrenzung der f\u00fcr Anfragen verf\u00fcgbaren Bereiche.\n
Der Befehl for-each-ref wurde um die Formatierungsoption «%(ahead-behind:<base>)» erweitert, die es erm\u00f6glicht, Informationen \u00fcber die Anzahl der Commits, die in einem bestimmten Branch vorhanden oder fehlen, im Verh\u00e4ltnis zu einem anderen Branch zu erhalten (wie sehr ein Branch hinter einem anderen zur\u00fcckbleibt oder ihn \u00fcbertrifft). Zuvor war es erforderlich, zwei separate Befehle auszuf\u00fchren, um \u00e4hnliche Informationen zu erhalten: «git rev-list —count main..my-feature» um die Anzahl der f\u00fcr den Branch einzigartigen Commits zu ermitteln und «git rev-list —count my-feature..main» um die Anzahl der fehlenden Commits zu ermitteln. Jetzt k\u00f6nnen solche Berechnungen auf einen einzigen Befehl reduziert werden, was die Erstellung von Handlern vereinfacht und die Ausf\u00fchrungszeit verk\u00fcrzt. Zum Beispiel kann man zur Anzeige nicht zusammengef\u00fchrter Branches und zur Bewertung ihrer R\u00fcckst\u00e4nde oder Fortschritte gegen\u00fcber dem Hauptbranch eine Einzeile verwenden: $ git for-each-ref —no-merged=origin\/HEAD \ —format=’%(refname:short) %(ahead-behind:origin\/HEAD)’ \ refs\/heads\/tb\/ | column -t tb\/cruft-extra-tips 2 96 tb\/for-each-ref—exclude 16 96 tb\/roaring-bitmaps 47 3 anstelle des zuvor verwendeten Skripts, das 17 Mal langsamer ausgef\u00fchrt wird: $ git for-each-ref —format=’%(refname:short)’ —no-merged=origin\/HEAD \ refs\/heads\/tb | while read ref do ahead=»$(git rev-list —count origin\/HEAD..$ref)» behind=»$(git rev-list —count $ref..origin\/HEAD)» printf «%s %d %d\n» «$ref» «$ahead» «$behind» done | column -t tb\/cruft-extra-tips 2 96 tb\/for-each-ref—exclude 16 96 tb\/roaring-bitmaps 47 3\n
Dem Befehl «git fetch» wurde die Option «—porcelain» hinzugef\u00fcgt, bei der die Ausgabe im Format «<flag> <old-object-id> <new-object-id> <local-reference>» erzeugt wird. Dieser ist weniger lesbar, jedoch besser f\u00fcr die Analyse in Scripts geeignet.\n
![\"Das](\"\/wp-content\/uploads\/2023\/06\/1158b26b1dfd1c16c93017669224d7a4.png\")
<\/center>\n![\"Das](\"\/wp-content\/uploads\/2023\/06\/ed6cb7102da37d1262fd3079ac983158.png\")
<\/center> <\/p>\n