{"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\/news\/dostupna-sistema-upravleniya-ishodnymi-tekstami-git-2-41","title":{"rendered":"Das System zur Verwaltung von Quelltexten 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 Systems zur Verwaltung von Quelltexten Git ver\u00f6ffentlicht. Git geh\u00f6rt zu den bekanntesten, zuverl\u00e4ssigsten und leistungsst\u00e4rksten Versionsverwaltungssystemen und bietet flexible Werkzeuge f\u00fcr nichtlineare Entwicklungen, die auf Verzweigungen und Zusammenf\u00fchrungen basieren. Um die Integrit\u00e4t der Historie und die Widerstandsf\u00e4higkeit gegen\u00fcber R\u00fcckwirkenden \u00c4nderungen zu gew\u00e4hrleisten, wird das gesamte fr\u00fchere Historie in jedem Commit implizit gehasht; au\u00dferdem ist die Verifizierung durch digitale Signaturen f\u00fcr bestimmte Tags und Commits m\u00f6glich. <\/p>\n
Im Vergleich zur vorherigen Version wurden in die neue Version 542 \u00c4nderungen \u00fcbernommen, die von 95 Entwicklern vorbereitet wurden, von denen 29 erstmals an der Entwicklung teilnahmen. Die Hauptneuerungen sind: <\/p>\n
\n
Die Verarbeitung unerreichbarer Objekte (unreachable) wurde verbessert, auf die im Repository keine Verweise (wie Branches oder Tags) existieren. Unerreichbare Objekte werden vom Garbage Collector entfernt, bleiben aber eine gewisse Zeit im Repository, um Zustandsrennen zu vermeiden. Um die Dauer des Aufenthalts unerreichbarer Objekte zu verfolgen, m\u00fcssen diese mit Zeitstempeln versehen werden, was es verhindert, sie in einer Pack-Datei zu speichern, in der alle Objekte einen gemeinsamen Zeitstempel haben. Fr\u00fcher wurde jedes unerreichbare Objekt in einer separaten Datei gespeichert, was zu Problemen f\u00fchren konnte, wenn viele neue unerreichbare Objekte vorhanden waren, die noch nicht zur L\u00f6schung f\u00e4llig waren. In der neuen Version wird standardm\u00e4\u00dfig der Mechanismus der 'cruft packs' verwendet, um unerreichbare Objekte in einer einzigen Pack-Datei zu speichern, wobei die \u00c4nderungsdaten jedes Objekts in einer separaten Tabelle erfasst werden, die in einer Datei mit der Erweiterung '.mtimes' gespeichert und \u00fcber eine Index-Datei mit der Erweiterung '.idx' verkn\u00fcpft wird.
<\/center>\n
Die F\u00fchrung eines Umkehrindex (revindex) f\u00fcr Pack-Dateien ist standardm\u00e4\u00dfig aktiviert. Bei Tests im Repository torvalds\/linux konnte durch die Verwendung des Umkehrindex die rechenintensive Operation 'git push' um den Faktor 1,49 beschleunigt werden, w\u00e4hrend einfache Operationen wie die Berechnung der Gr\u00f6\u00dfe eines Objekts mit 'git cat-file --batch='%(objectsize:disk)' um das 77-fache beschleunigt wurden. Die Dateien ('.rev') mit dem Umkehrindex werden im Repository im Verzeichnis '.git\/objects\/pack' gespeichert.\n
Erinnern wir uns daran, dass Git alle Daten in Form von Objekten speichert, die in separaten Dateien abgelegt werden. Um die Effizienz der Arbeit mit dem Repository zu erh\u00f6hen, werden die Objekte zus\u00e4tzlich in Pack-Dateien abgelegt, in denen die Informationen in Form eines Stroms von aufeinanderfolgenden Objekten dargestellt werden (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, anhand der Objekt-ID sehr schnell die Offsets in der Pack-Datei zu bestimmen, wo dieses Objekt gespeichert ist. <\/p>\n
Der im neuen Release enthaltene umgekehrte Index zielt darauf ab, den Prozess der Identifizierung von Objekten anhand der Platzierungsinformationen im Pack-File zu optimieren. Zuvor wurde diese Umwandlung zur Laufzeit w\u00e4hrend der Analyse des Pack-Files durchgef\u00fchrt und nur im Speicher gespeichert, was es nicht erm\u00f6glichte, solche Indizes wiederzuverwenden und die Erstellung des Index jedes Mal erforderlich machte. Der Vorgang zum Erstellen des Index besteht darin, ein Array aus Paaren \u201eObjekt-Position\u201c zu erstellen und es nach Position zu sortieren, was bei gro\u00dfen Pack-Files viel Zeit in Anspruch nehmen kann. <\/p>\n
Zum Beispiel wurde die Ausgabe des Inhalts von Objekten, bei der ein direkter Index verwendet wurde, 62-mal schneller durchgef\u00fchrt als die Anzeige der Gr\u00f6\u00dfe von Objekten, f\u00fcr die die Daten zur Beziehung zwischen Position und Objekt nicht indiziert wurden. Nach der Verwendung des R\u00fcckw\u00e4rtsindex ben\u00f6tigten die genannten Operationen etwa die gleiche Zeit. R\u00fcckw\u00e4rtsindizes erm\u00f6glichen es auch, die Vorg\u00e4nge beim Senden von Objekten bei den Befehlen fetch und push durch die direkte \u00dcbertragung bereits bereitgestellter Daten von der Festplatte zu beschleunigen.
<\/center> <\/p>\n
Im \u201eCredential Helper\u201c-Protokoll, das zum \u00dcbertragen von Anmeldeinformationen beim Zugriff auf Repositories mit eingeschr\u00e4nktem Zugriff verwendet wird, wurde die Unterst\u00fctzung f\u00fcr die \u00dcbertragung von WWW-Authenticate-Headern zwischen dem Anmeldeinformations-Handler und dem Service, bei 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 Benutzerzugriffssteuerung auf Repositories und die Abgrenzung der Bereiche, die f\u00fcr Anfragen verf\u00fcgbar sind.\n
Der Befehl for-each-ref wurde um die Formatierungsoption «%(ahead-behind:<base>)» erg\u00e4nzt, die es erm\u00f6glicht, Informationen \u00fcber die Anzahl der Commits zu erhalten, die in einem bestimmten Branch im Vergleich zu einem anderen Branch vorhanden oder nicht vorhanden sind (wie viel ein Branch dem anderen in Bezug auf Commits hinterherhinkt oder voraus ist). Zuvor war es n\u00f6tig, zwei separate Befehle auszuf\u00fchren: «git rev-list —count main..my-feature», um die Anzahl der f\u00fcr den Branch einzigartigen Commits zu erhalten, und «git rev-list —count my-feature..main» f\u00fcr die Anzahl der fehlenden Commits. Jetzt k\u00f6nnen solche Berechnungen auf einen einzigen Befehl reduziert werden, was das Schreiben von Handhabungen vereinfacht und die Ausf\u00fchrungszeit verk\u00fcrzt. Beispielsweise kann zur Anzeige von nicht zusammengef\u00fchrten Branches und zur Bewertung des R\u00fcckstands oder der Vorlaufzeit im Vergleich zu ihrem Hauptbranch ein Einzeiler verwendet werden: $ 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 eines 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
Der Befehl «git fetch» wurde um die Option «—porcelain» erg\u00e4nzt, deren Verwendung zu einer Ausgabe im Format «<flag> <alter-objekt-id> <neue-objekt-id> <lokale-referenz>» f\u00fchrt, die weniger lesbar, aber besser f\u00fcr die Analyse in Skripten geeignet ist.\n
![\"Das](\"\/wp-content\/uploads\/2023\/06\/1158b26b1dfd1c16c93017669224d7a4.png\")
<\/center>\n![\"Das](\"\/wp-content\/uploads\/2023\/06\/ed6cb7102da37d1262fd3079ac983158.png\")
<\/center> <\/p>\n