{"id":121313,"date":"2025-01-11T21:46:00","date_gmt":"2025-01-11T19:46:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-48"},"modified":"2025-01-11T21:46:00","modified_gmt":"2025-01-11T19:46:00","slug":"vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-48","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-48","title":{"rendered":"Ver\u00f6ffentlichung des Versionskontrollsystems Git 2.48","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Die Ver\u00f6ffentlichung des verteilten Systems zur Verwaltung von Quelltexten Git 2.48 wurde ver\u00f6ffentlicht. Git zeichnet sich durch hohe Leistungsf\u00e4higkeit aus und bietet Mittel zur nichtlinearen Entwicklung, die auf Branching und Merging basieren. Zum Schutz der Integrit\u00e4t der Historie und der Resistenz gegen nachtr\u00e4gliche \u00c4nderungen wird das gesamte vorherige Geschehen in jedem Commit implizit gehasht, und es werden digitale Signaturen der Entwickler f\u00fcr einzelne Tags und Commits verwendet. Der Code von Git wird unter der GPLv2+-Lizenz verbreitet. <\/p>\n
Im Vergleich zur vorherigen Version wurden in die neue Version 605 \u00c4nderungen aufgenommen, die mit Unterst\u00fctzung von 93 Entwicklern vorbereitet wurden, von denen 35 erstmals an der Entwicklung beteiligt sind. Die wichtigsten Neuerungen: <\/p>\n
\n
Die M\u00f6glichkeit, mit dem Build-System Meson zu bauen, wurde zus\u00e4tzlich zu GNU Make und CMake implementiert. Git kann jetzt mit dem Befehl \u201emeson setup build && ninja -C build\u201c gebaut werden. Es wird angemerkt, dass die Makefile, die bei der Verwendung von GNU Make verwendet wird, auf 3887 Zeilen angewachsen ist und nicht so einfach ist, wie man es sich w\u00fcnschen w\u00fcrde. Das Meson-Tool erleichtert die Arbeit mit dem Build-System, ist benutzerfreundlich f\u00fcr plattform\u00fcbergreifende Builds und macht den Build-Prozess zug\u00e4nglicher f\u00fcr Anf\u00e4nger oder Entwickler, die keine Erfahrung mit dem Tool Make haben. Es sind keine Pl\u00e4ne bekannt, die Unterst\u00fctzung f\u00fcr Make und CMake in naher Zukunft einzustellen.\n
Es wurden Build-Optionen hinzugef\u00fcgt, die alternative Implementierungen des SHA-1-Hashes erm\u00f6glichen, um Pr\u00fcfziffern zu berechnen, die zur \u00dcberpr\u00fcfung der Integrit\u00e4t von Datenbl\u00f6cken in Pack-Dateien verwendet werden. Die Leistung bei der Berechnung von Pr\u00fcfziffern ist entscheidend, z. B. werden beim Klonen des Linux-Kernel-Repositories etwa 78 % der Prozessorzeit f\u00fcr deren Berechnung aufgewendet. Die standardm\u00e4\u00dfig verwendete Implementierung enth\u00e4lt zus\u00e4tzliche Kollisionspr\u00fcfungen und Schutzmechanismen gegen Angriffe auf SHA-1 wie SHAttered und Shambles. solcher Schutz, der zus\u00e4tzliche Ressourcen ben\u00f6tigt, ist nur sinnvoll, wenn SHA-1 f\u00fcr kryptographische Zwecke verwendet wird und ist nutzlos bei der \u00dcberpr\u00fcfung der Integrit\u00e4t von Indexdaten.\n
F\u00fcr den Bau von Git mit einer schnelleren Implementierung von SHA-1, die nicht f\u00fcr kryptografische Systeme geeignet ist, wurde eine Reihe von Optionen *_UNSAFE vorgeschlagen, beispielsweise \u201eOPENSSL_SHA1_UNSAFE\u201c. Bei GitHub hat der Build mit der vereinfachten SHA-1 es erm\u00f6glicht, die Leistung von Abruf- und Klonoperationen um 10-13% zu steigern. <\/p>\n
Die M\u00f6glichkeit, in dem Befehl \u201erange-diff\u201c die Option \u201e--remerge-diff\u201c zu verwenden, wurde hinzugef\u00fcgt. Damit lassen sich Unterschiede zwischen dem Gesamtergebnis des Mergings und den tats\u00e4chlichen Daten, die im Commit nach der Ausf\u00fchrung des Befehls \u201emerge\u201c reflektiert werden, anzeigen. Bei Verwendung der Option \u201e--remerge-diff\u201c werden die Unterschiede in den Konfliktl\u00f6sungen nicht f\u00fcr jeden \u00fcbergeordneten Branch getrennt, sondern es werden die gemeinsamen Unterschiede zwischen der Datei mit den Merge-Konflikten und der Datei angezeigt, in der die Konflikte gel\u00f6st wurden. Im Kontext des Befehls \u201erange-diff\u201c k\u00f6nnte die neue Option n\u00fctzlich sein, um Commit-Sets nach der \u00dcbertragung der Commit-Reihenfolge mit dem Befehl \u201erebase\u201c und der Option \u201e--rebase-merges\u201c zu vergleichen.\n
Die M\u00f6glichkeit, eine Git-Testreihe im Modus zur Erkennung von Speicherlecks auszuf\u00fchren, wurde hinzugef\u00fcgt. Da Git Dienstprogramme bereitstellt, die nach der Ausf\u00fchrung der aufgerufenen Funktion beendet werden, wurden Speicherlecks fr\u00fcher nicht als gro\u00dfes Problem angesehen. Die Notwendigkeit zur vollst\u00e4ndigen Beseitigung von Speicherlecks ist relevanter geworden, nachdem mit der Auslagerung interner Funktionalit\u00e4ten in eine separate Bibliothek begonnen wurde, die in langlebigen Prozessen verwendet werden kann.\n
Die Erstellung einer Liste veralteter Funktionen und Modi hat begonnen, deren Unterst\u00fctzung in Zukunft eingestellt werden soll. Es wird erwartet, dass die Entfernung der veralteten Funktionalit\u00e4t in der Version Git 3.0 erfolgt, die \u00c4nderungen enthalten wird, die die Abw\u00e4rtskompatibilit\u00e4t brechen.\n
Die Optimierung des Befehls \u201egit for-each-ref\u201c, der eine Liste von Referenzen im Repository ausgibt, wurde fortgesetzt. Die Optimierung, die die Handler f\u00fcr die Filterung von Referenzen und die Formatierung der Ausgabe zusammenf\u00fchrt, wird nun nicht nur f\u00fcr unsortierte Ausgaben, sondern auch bei Angabe der Option \u201e--sort\u201c angewendet.\n
Die Implementierung des Backends \u201ereftable\u201c mit einer blockbasierten Speicherung zur effektiven Speicherung von Referenzen auf Branches und Tags im Repository wurde verbessert. Reftable erm\u00f6glicht signifikante Geschwindigkeitssteigerungen beim Suchen, Lesen und Schreiben in Repositories mit einer sehr hohen Anzahl an Referenzen. In der neuen Version wurde auf einige Hilfs-APIs verzichtet, um die Bibliothek libgit weiter aus den Build-Abh\u00e4ngigkeiten zu entfernen. Eine adaptive Fehlerbehandlung wurde implementiert, bei der Speicherallokationsfehler (Speicherknappheit f\u00fchrt jetzt nicht mehr zu einem Absturz) behoben wurden. Die Erstellung von Referenzen wurde beschleunigt und der Speicherverbrauch gesenkt.\n
Bei der Implementierung des partiellen Klonens wurden Probleme behoben, die zu Schleifen und zur Besch\u00e4digung des Repositories nach der Ausf\u00fchrung des Befehls \u201egit gc\u201c f\u00fchrten.\n
Beim Ausf\u00fchren des Befehls \u201egit fetch \u201c wird, falls auf dem lokalen System \u201erefs\/remotes\/\/HEAD\u201c nicht vorhanden ist und auf der anderen Seite ein Branch existiert, auf den HEAD verweist, \u201erefs\/remotes\/\/HEAD\u201c jetzt auf diesen Branch umgeleitet. Um die Synchronisierung von \u201erefs\/remotes\/\/HEAD\u201c mit dem Wert von HEAD auf der anderen Seite der Verbindung zu verwalten, wurde die Einstellung remote..followRemoteHEAD hinzugef\u00fcgt.\n
Die Einstellung \u201eremote..serverOption\u201c wurde hinzugef\u00fcgt, \u00e4hnlich der Befehlszeilenoption \u201e--serverOption=\u201c.\n
Im Befehl \u201egit rebase --rebase-merges\u201c wurde nach M\u00f6glichkeit sichergestellt, dass Branch-Namen als Tags verwendet werden.\n
In den Befehlen \u2018git notes add\u2019 und \u2018git notes append\u2019 wurde die Option \u2018-e\u2019 hinzugef\u00fcgt, die eine Notiz in einem externen Texteditor \u00f6ffnet, der \u00fcber die Umgebungsvariable GIT_EDITOR angegeben ist.\n
Die Kompatibilit\u00e4t mit GCC 15 und dem C23 Standard wurde verbessert.\n
Die Unterst\u00fctzung f\u00fcr \u00e4ltere Versionen von libcURL und Perl wurde eingestellt. <\/ul>\n