{"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\/news\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-48","title":{"rendered":"Ver\u00f6ffentlichung des Versionsverwaltungssystems Git 2.48","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Die Ausgabe des verteilten Systems zur Verwaltung von Quelltexten Git 2.48 wurde ver\u00f6ffentlicht. Git zeichnet sich durch hohe Leistung aus und bietet Werkzeuge f\u00fcr die nicht-lineare Entwicklung, die auf Branching und Merging basieren. Um die Integrit\u00e4t der Historie und die Best\u00e4ndigkeit gegen\u00fcber 'r\u00fcckblickenden' \u00c4nderungen zu gew\u00e4hrleisten, wird ein implizites Hashing der gesamten vorherigen Historie in jedem Commit verwendet, zusammen mit der digitalen Signatur von Entwicklern f\u00fcr einzelne Tags und Commits. Der Code von Git wird unter der Lizenz GPLv2+ verbreitet. <\/p>\n
Im Vergleich zur vorherigen Version enth\u00e4lt die neue Version 605 \u00c4nderungen, die von 93 Entwicklern, von denen 35 erstmals an der Entwicklung beteiligt sind, vorbereitet wurden. Die wichtigsten Neuerungen sind: <\/p>\n
\n
Es wurde die M\u00f6glichkeit f\u00fcr den Bau mit dem Build-System Meson neben GNU Make und CMake implementiert. Zum Bauen von Git kann jetzt der Befehl 'meson setup build && ninja -C build' verwendet werden. Es wird angemerkt, dass das Makefile, das bei der Verwendung von GNU Make verwendet wird, auf 3887 Zeilen angewachsen ist und nicht so einfach ist, wie man w\u00fcnschen w\u00fcrde. Das Meson-Toolkit vereinfacht die Arbeit mit dem Build-System, ist benutzerfreundlich f\u00fcr plattform\u00fcbergreifende Builds und macht das Bauen f\u00fcr Anf\u00e4nger oder Entwickler ohne Erfahrung mit dem Make-Tool zug\u00e4nglicher. Eine Beendigung der Unterst\u00fctzung von Make und CMake ist in naher Zukunft nicht geplant.\n
Es wurden neue Build-Optionen hinzugef\u00fcgt, die alternative Implementierungen des SHA-1-Hashes beim Berechnen von Pr\u00fcfziffern erm\u00f6glichen, die zur Gew\u00e4hrleistung der Integrit\u00e4t von Datenbl\u00f6cken in Pack-Dateien verwendet werden. Die Leistung der Pr\u00fcfziffernberechnungen ist von gro\u00dfer Bedeutung; beispielsweise entfallen beim Klonen eines Repositories mit dem Linux-Kernel etwa 78 % der Prozessorzeit auf deren Berechnung. Die standardm\u00e4\u00dfig verwendete Implementierung umfasst zus\u00e4tzliche Kollisionspr\u00fcfungen und Schutzma\u00dfnahmen gegen Angriffe auf SHA-1 wie SHAttered und Shambles. Ein solcher Schutz, der zus\u00e4tzliche Ressourcen beansprucht, ist nur sinnvoll, wenn SHA-1 zu kryptografischen Zwecken verwendet wird, und nutzlos bei der \u00dcberpr\u00fcfung der Integrit\u00e4t von Indexdaten.\n
F\u00fcr den Bau von Git mit einer schnelleren SHA-1-Implementierung, die f\u00fcr kryptographische Systeme ungeeignet ist, wurde eine Reihe von Optionen *_UNSAFE vorgeschlagen, wie 'OPENSSL_SHA1_UNSAFE'. Bei GitHub konnte der Bau mit der vereinfachten SHA-1-Implementierung die Leistung von Abruf- und Klonvorg\u00e4ngen um 10-13% steigern. <\/p>\n
Die M\u00f6glichkeit, im Befehl 'range-diff' die Option '--remerge-diff' zu verwenden, wurde hinzugef\u00fcgt, um die Unterschiede zwischen dem gemeinsamen Ergebnis des Merge und den tats\u00e4chlichen Daten darzustellen, die im Commit nach der Ausf\u00fchrung des 'merge'-Befehls reflektiert werden. Bei Verwendung der Option '--remerge-diff' werden die Unterschiede zwischen den Konfliktl\u00f6sungen nicht f\u00fcr jeden \u00fcbergeordneten Branch getrennt angezeigt, sondern die allgemeinen Unterschiede zwischen der Datei mit Merge-Konflikten und der Datei, in der die Konflikte gel\u00f6st wurden, werden dargestellt. Im Kontext des 'range-diff'-Befehls kann die neue Option n\u00fctzlich sein, um Commit-Sets nach dem \u00dcbertragen der Commit-Reihenfolge mit dem 'rebase'-Befehl mit der Option '--rebase-merges' zu vergleichen.\n
Die M\u00f6glichkeit, einen Git-Testbefehl im Modus zur Erkennung von Speicherlecks auszuf\u00fchren, wurde hinzugef\u00fcgt. Da Git Werkzeuge bereitstellt, die nach der Ausf\u00fchrung der aufgerufenen Funktion beendet werden, wurden Speicherlecks fr\u00fcher nicht als gro\u00dfes Problem betrachtet. Die Notwendigkeit, Speicherlecks vollst\u00e4ndig zu beseitigen, wurde relevant, nachdem mit der Auslagerung interner Funktionen in eine separate Bibliothek begonnen wurde, die in lang laufenden Prozessen eingesetzt werden kann.\n
Es wurde mit der Erstellung einer Liste veralteter Modi und Funktionen begonnen, deren Unterst\u00fctzung k\u00fcnftig eingestellt werden soll. Es wird angenommen, dass die Entfernung veralteter Funktionen in der Git-Version 3.0 erfolgen wird, die \u00c4nderungen enthalten wird, die die Abw\u00e4rtskompatibilit\u00e4t beeintr\u00e4chtigen.\n
Die Optimierung der Funktionsweise des Teams «git for-each-ref», das eine Liste von Verweisen im Repository ausgibt, wurde fortgesetzt. Die Optimierung, die Handler f\u00fcr die Filterung von Verweisen und die Formatierung der Ausgabe kombiniert, wird nun nicht nur f\u00fcr unsortierte Ausgaben, sondern auch bei Angabe der Option «—sort» angewendet.\n
Die Implementierung des Backends «reftable» mit Blockspeicher wurde verbessert, um die Speicherung von Verweisen auf Zweige und Tags im Repository effizient zu gestalten. Reftable erm\u00f6glicht eine deutlich schnellere Suche, Lese- und Schreiboperationen in Repositories mit einer sehr gro\u00dfen Anzahl von Verweisen. In der neuen Version wird der Zugriff auf einige Hilfs-APIs eingestellt, um die Bibliothek libgit aus den Build-Abh\u00e4ngigkeiten zu entfernen. Eine adaptive Fehlerbehandlung wurde implementiert, um die von Speicherzuweisungsfunktionen zur\u00fcckgegebenen Fehler zu verarbeiten (Speicherknappheit f\u00fchrt jetzt nicht mehr zu einem Absturz). Die Vorg\u00e4nge zur Erstellung von Verweisen wurden beschleunigt und der Speicherverbrauch reduziert.\n
Bei der Implementierung des partiellen Klonens wurden Probleme behoben, die zu Endlosschleifen und Besch\u00e4digungen des Repositories nach der Ausf\u00fchrung des Befehls «git gc» f\u00fchrten.\n
Beim Ausf\u00fchren des Befehls «git fetch <remote>» wird jetzt, wenn «refs\/remotes\/<remote>\/HEAD» auf dem lokalen System fehlt und auf der anderen Seite ein Branch vorhanden ist, auf den HEAD verweist, «refs\/remotes\/<remote>\/HEAD» auf diesen Branch umgeleitet. Um die Synchronisation von «refs\/remotes\/<remote>\/HEAD» mit dem HEAD auf der anderen Seite der Verbindung zu steuern, wurde die Einstellung remote.<remote>.followRemoteHEAD» hinzugef\u00fcgt.\n
Die Einstellung «remote.<name>.serverOption» wurde hinzugef\u00fcgt, die der Option «—serverOption=<value>» der Befehlszeile entspricht.\n
Im Befehl «git rebase —rebase-merges» wird nach M\u00f6glichkeit die Verwendung von Branch-Namen als Tags sichergestellt.\n
Den Befehlen ‘git notes add’ und ‘git notes append’ wurde die Option ‘-e’ hinzugef\u00fcgt, die eine Notiz in einem externen Texteditor \u00f6ffnet, der \u00fcber die Umgebungsvariable GIT_EDITOR angegeben wird.\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