Git 2.48 fĂĽhrt neues Build-System ein und beschleunigt SHA-1 intern
Mit Meson lässt sich in Git 2.48 ein neues Build-System verwenden, das eine einfache Syntax bietet und für viele IDEs verfügbar ist.
(Bild: erstellt mit Dall-E durch iX)
In Version 2.48 führt die Versionsverwaltung Git mit Meson ein neues Build-System ein, verbessert in einigen Punkten die Sicherheit und bringt ein paar neue Befehle mit. Entwicklerinnen und Entwickler können künftig Meson neben Make, CMake und Autoconf verwenden, das einige Vorteile bietet: Es erleichtert das Auffinden von Build-Optionen, hat im Vergleich zu den Vorgängern eine einfachere Syntax, bietet moderne Build-Funktionen und unterstützt verschiedene Betriebssysteme, Compiler sowie IDEs.
Ein praktisches Hilfsmittel ist beispielsweise der Befehl meson configure, mit dem Anwender eine Konfiguration innerhalb eines Build-Verzeichnisses einsehen oder ändern. Und meson setup <build_dir> richtet mehrere Build-Verzeichnisse ein. Weitere Infos finden sich in der Datei meson.build im Git-Repository. Das alte Make-System war in die Jahre gekommen: Zum aktuellen Makefile haben 2000 Commits beigetragen und das Build-Skript besteht aus 4000 Zeilen Code.
Weniger Speicherlecks fĂĽr eine neue Library
In puncto Sicherheit war das Git-Team bestrebt, sämtliche Speicherlecks auszumerzen. Da Git auf der Kommandozeile arbeitet, stellen die Lecks zwar kein größeres Problem dar, da der Kernel die nicht freigegebenen Bereiche kurzfristig kassiert. Ziel des Git-Teams ist jedoch, Teile der Versionsverwaltung in eine Bibliothek zu portieren, wo Lecks ein ernsteres Problem bedeuten. Alle bekannten Löcher sind nun gestopft, und Git 2.48 hat die entsprechenden Tests fehlerfrei passiert.
Nur am Rande ein Sicherheitsthema ist die kollisionsfreie Verwendung von SHA-1. Git verwendet diesen Hash-Algorithmus intern zum Beispiel beim Packen und dreht dabei ein paar Extrarunden in der Berechnung, um die Datenintegrität zu sichern, die bei SHA-1 in einigen Fällen nicht gegeben ist. Anwenderinnen und Anwender, die aus Performancegründen darauf verzichten möchten, können dies beim Build mit make OPENSSL_SHA1_UNSAFE=1 erzwingen. SHA-256 lässt sich nur auf Ebene der Repositorys der Anwender einstellen, und zwar mit git init --object-format=sha256 repo. SHA-256 weist weniger Kollisionsprobleme auf.
Weitere Neuerungen: Die Option --remerge diff lässt sich nun beim Befehl range diff verwenden, um Merge Commits nach einem Rebase sichtbar zu machen. Das relativ neue Reftable-Subsystem wurde beschleunigt, durch das Abtrennen von Convenience-APIs und die Wiederverwendung von Iterators beim Zugriff auf Referenzen.
Weitere Details finden sich in der offiziellen AnkĂĽndigung und den Blogs von GitHub sowie GitLab.
(who)