Blog Open Source Was gibt es Neues in Git 2.48.0?
Aktualisiert am: January 20, 2025
7 Minuten Lesezeit

Was gibt es Neues in Git 2.48.0?

Erfahre, was dich in der neuesten Version von Git erwartet, darunter ein neues Build-System und eine Optimierung im neuen reftables-Backend. Entdecke Beiträge des Git-Teams von GitLab und der Git-Community.

git 2 - cover

Das Git-Projekt hat kürzlich Git 2.48.0. Werfen wir einen Blick auf die wichtigsten Highlights dieser Version, die Beiträge des Git-Teams von GitLab und der gesamten Git-Community enthält.

Meson-Build-System

Lange Zeit konnte Git entweder mit einem auf Makefile oder auf Autoconf basierenden Build-System erstellt werden. Git-Entwickler(innen) verwendeten bis jetzt hauptsächlich das auf Makefile basierende Build-System, weshalb das auf Autoconf basierende Build-System hinsichtlich Funktionen und Wartung hinterherhinkte. Ein weiteres Problem war, dass viele Windows-Entwickler(innen) integrierte Entwicklungsumgebungen (IDEs) verwendeten, die auf Makefile und Autoconf basierende Build-Systeme nicht gut unterstützten.

Im Jahr 2020 wurde die Unterstützung für die Entwicklung um Git und CMake ergänzt. CMake bot eine bessere Windows-Unterstützung und IDE-Integration, insbesondere für Visual Studio. Einige moderne Build-Systemfunktionen wie Out-of-Source-Builds waren ebenfalls enthalten.

Vor kurzem schien es, dass der CMake-Support ebenfalls hinterherhinkte und dass es vielleicht keine gute Idee wäre, die beiden anderen Build-Systeme zu ersetzen. Also implementierte Patrick Steinhardt, GitLab Git Engineering Manager, Unterstützung für das Meson-Build-System. Ziel dabei war, irgendwann die auf Autoconf, CMake und vielleicht sogar Makefile basierenden Build-Systeme zu ersetzen.

Das neue, auf Meson basierende Build-System hat folgende Vorteile:

  • Benutzer(innen) können die verfügbaren Build-Optionen einfacher finden, was mit Makefiles und CMake schwierig ist.
  • Einfache Syntax im Vergleich zu Autoconf und CMake.
  • Viele verschiedene Betriebssysteme, Compiler und IDEs werden unterstützt.
  • Moderne Build-Systemfunktionen wie Out-of-Source-Builds werden unterstützt.

Hier ist ein Beispiel dafür, wie es tatsächlich zum Erstellen von Git verwendet werden kann:

$ cd git             	# go into the root of Git's source code
$ meson setup build/ 	# setup "build" as a build directory
$ cd build           	# go into the "build" directory
$ meson compile      	# actually build Git
$ meson test         	# test the new build
$ meson install      	# install the new build

Mit meson setup <build_dir> können mehrere Build-Verzeichnisse eingerichtet werden, und die Konfiguration des Builds in einem Build-Verzeichnis kann durch Ausführen von meson configure im Build-Verzeichnis angezeigt oder geändert werden.

Weitere Informationen zum Erstellen von Git mit Meson findest du oben in der Datei meson.build im Git-Code-Repository. Ein Vergleich der verschiedenen Build-Systeme für Git ist als Teil der technischen Dokumentation von Git verfügbar.

Dieses Projekt wurde von Patrick Steinhardt geleitet.

Git ist hat jetzt keine Speicherlecks mehr (wie von der Testsuite ausgeführt)

In unserem Git-Release-Blogbeitrag zur vorherigen Release Git 2.47.0 sprachen wir über unsere laufenden Bemühungen, alle Speicherlecks zu beheben, die durch bestehende Tests im Projekt aufgedeckt wurden. Wir sagten, dass das Projekt vor der Git-Release 2.47.0 223 Testdateien hatte, die Speicherlecks enthielten, und dass dies nun auf 60 reduziert wurde.

Wir freuen uns, dass die Speicherlecks jetzt in allen 60 verbleibenden Testdateien behoben wurden. Dadurch hat Git, wie von der Testsuite gezeigt, nun keine Speicherlecks mehr. Dies ist ein wichtiger Schritt in Richtung des langjährigen Ziels, Git-interne Komponenten zu „libifizieren“ (also diese Komponenten in interne Bibliotheken zu konvertieren). Außerdem trägt es dazu bei, Git für die Speichernutzung zu optimieren.

Nun darf jeder neu hinzugefügte Test standardmäßig kein Leck enthalten. Es ist immer noch möglich, Tests mit Lecks zu haben, aber die Autor(inn)en müssen dafür eine Notlösung haben und gute Argumente liefern, warum der Test nicht ohne Lecks erstellt werden kann.

Dieses Projekt wurde von Patrick Steinhardt geleitet.

Verbesserte Bundle-URI-Checks

In unserem Git-Release-Blogbeitrag zur Release von Git 2.46.0 sprachen wir über einige Bundle-URI-Fixes von Xing Xin. Nach diesen Korrekturen arbeitete Xing Xin daran, dass Abrufe mit Bundles vollständig mit dem fsck-Mechanismus wie reguläre Abrufe überprüft werden konnten.

Bei der Validierung von regelmäßigen Abrufen ist es möglich, verschiedene Schweregrade für verschiedene fsck-Probleme festzulegen, um feiner steuern zu können, was in einem bestimmten Repository akzeptiert und was abgelehnt wird. Dies war zuvor für Abrufe mit Bundles nicht möglich.

Um den Nutzen und die Sicherheit von Bundle-URIs weiter zu erhöhen, haben wir dieses Problem behoben, damit die verschiedenen Schweregrade, die für verschiedene fsck-Probleme festgelegt wurden, jetzt auch bei der Überprüfung von Abrufen mit Bundles verwendet werden können.

Dieses Projekt wurde von Justin Tobler geleitet.

Referenzkonsistenzprüfungen hinzufügen

In unserem Blogbeitrag zur Release von Git 2.47.0 erwähnten wir die Arbeit von Jialuo She an dem [neuen Unterbefehl „Verify“](https://about.gitlab.com/de-de/blog/2024/10/07/whats-new-in-git-2-47-0/#new-subcommand-for-git-refs(1) zu git-refs(1), der Teil des Google Summer of Code 2024 (GSoC 2024) war.

In diesem Blogbeitrag erläuterten wir, dass das Ziel schlussendlich darin bestand, diesen neuen Unterbefehl als Teil von git-fsck(1) zu integrieren und dadurch eine vereinheitlichte Möglichkeit zu schaffen, Konsistenzüberprüfungen von Repositories durchzuführen. Jialuo She hat beschlossen, daran zu arbeiten, nachdem sein GSoC vorbei war.

Das Ergebnis dieser Arbeit ist, dass git-fsck(1) jetzt eine Reihe von referenzbezogenen Problemen erkennen und beheben kann, z. B. wenn der Inhalt einer Referenz schlecht ist, wenn ein symbolischer Link als symbolische Referenz verwendet wird oder wenn das Ziel einer symbolischen Referenz nicht auf eine gültige Referenz verweist. Wir müssen weiterhin git refs verify als Teil von git-fsck(1) aufrufen und erstere alle nicht backendspezifischen Überprüfungen durchführen lassen, die letztere derzeit durchführt, aber wir sind unserem Ziel einer vereinheitlichten Möglichkeit, alle Konsistenzüberprüfungen von Refs durchzuführen, ein Stückchen näher gekommen.

Dieses Projekt wurde von Jialuo She geleitet.

Iterator-Wiederverwendung in reftables

In der Version Git 2.45.0 wurde das reftables-Format als neues Backend zum Speichern von Referenzen (meist Branches und Tags) eingeführt. Wenn du mit dem reftables-Backend noch nicht vertraut bist, lies dir unseren letzten Blogbeitrag zur Git-Release durch, in dem das Feature vorgestellt wurde. Auch unsere Anfängerleitfaden ist toll, um mehr darüber zu erfahren, wie reftables funktionieren.

Seit dieser Release haben wir dieses Backend weiter verbessert und uns in letzter Zeit darauf konzentriert, seine Leistung zu verbessern, indem wir beim Lesen zufälliger Referenzen einige interne Iteratoren wiederverwenden. Vor diesen Änderungen musste beim Lesen einer einzelnen Referenz ein ganz neuer Iterator erstellt, an der richtigen Stelle in den jeweiligen Tabellen gesucht und dann der nächste Wert daraus gelesen werden, was beim Lesen vieler Referenzen in schneller Folge ziemlich ineffizient sein kann. Nach der Änderung erstellen wir jetzt nur noch einen einzigen Iterator und verwenden ihn wieder, um mehrere Referenzen zu lesen, wodurch wir etwas Overhead sparen.

Dadurch verbessert sich die Leistung in einer Reihe von reftables-bezogenen Anwendungsfällen, so etwa ist das Erstellen vieler Referenzen in einer Transaktion, die viele zufällige Lesevorgänge durchführt, um 7 % schneller. Darüber hinaus schafft dies die Möglichkeit für weitere Optimierungen, da wir weiterhin mehr Zustände in den Iteratoren wiederverwenden können.

Dieses Projekt wurde von Patrick Steinhardt geleitet.

Unterstützung für reflogs in git-refs migrate

Nachdem das reftables-Backend in Git 2.45.0 eingeführt wurde (siehe obigen Abschnitt), haben wir in Git 2.46.0 an Tools zur Migration von Referenz-Backends gearbeitet. Ziel war, einen neuen Unterbefehl migrate zu git-refs(1) hinzuzufügen.

Im Artikel über Git 2.46.0 ging es um diese Arbeit und einige der Einschränkungen, die noch existierten. In dem Artikel heißt es insbesondere:

„Die reflogs in einem Repository werden auch über das Referenz-Backend gespeichert und würden ebenfalls eine Formatmigration erfordern. Leider ist das Tool noch nicht in der Lage, reflogs zwischen den files- und reftables-Backends zu konvertieren.“

Wir freuen uns, dass wir diese Einschränkung in Git 2.48.0 behoben haben. Reflogs können jetzt auch mit git refs migrate migriert werden. Das Migrationstool ist noch nicht in der Lage, ein Repository mit mehreren Arbeitsbäumen zu verwalten, aber dies ist die einzige verbleibende Einschränkung. Wenn du keine Arbeitsbäume verwendest, kannst du das reftables-Backend bereits in deinen vorhandenen Repositories nutzen.

Dieses Projekt wurde von Karthik Nayak geleitet.

Optimierung von „ref-filter“

Das Subsystem „ref-filter“ ist ein Formatierungscode, der von Befehlen wie git for-each-ref, git branch und git tag verwendet wird, um Informationen zu Git-Referenzen zu sortieren, zu filtern, zu formatieren und anzuzeigen.

Wenn Repositories wachsen, können sie eine große Anzahl von Referenzen enthalten. Aus diesem Grund arbeiten wir nicht nur daran, Backends zu verbessern, die Referenzen speichern, wie das reftables-Backend (siehe oben), sondern auch den Formatierungscode zu optimieren, wie zum Beispiel das Subsystem „ref-filter“.

Wir haben kürzlich einen Weg gefunden, wie wir vermeiden können, dass Referenzen vorübergehend gepuffert und im ref-Filtercode mehrmals wiederholt werden, wenn sie in der gleichen Sortierreihenfolge verarbeitet werden sollen, wie sie von den Backends bereitgestellt wird. Dies führt zu Speichereinsparungen und macht bestimmte Befehle in einigen Fällen bis zu 770-mal schneller.

Dieses Projekt wurde von Patrick Steinhardt geleitet.

Weiterlesen

In diesem Blogbeitrag werden nur einige der Beiträge von GitLab und der ganzen Git-Community für diese neueste Release vorgestellt. Diese kannst du in der offiziellen Versionsankündigung des Git-Projekts nachlesen. Sieh dir auch unsere letzten Blogbeiträge zu Git-Releases an, um weitere wichtige Beiträge von GitLab-Teammitgliedern zu entdecken.

Wir möchten gern von dir hören

Hat dir dieser Blogbeitrag gefallen oder hast du Fragen oder Feedback? Erstelle ein neues Diskussionsthema im GitLab Community-Forum und tausche deine Eindrücke aus. Teile dein Feedback

Bist du bereit?

Sieh dir an, was dein Team mit einer einheitlichen DevSecOps-Plattform erreichen könnte.

Kostenlose Testversion anfordern

Finde heraus, welcher Tarif für dein Team am besten geeignet ist

Erfahre mehr über die Preise

Erfahre mehr darüber, was GitLab für dein Team tun kann

Sprich mit einem Experten/einer Expertin