Versionsverwaltung: Git 2.38 kuratiert große Repositories mit Scalar

Die Quellcode-Versionsverwaltung Git ist in Version 2.38 erschienen. Das Highlight dürfte diesmal Scalar sein, ein neues Tool für Repositories. Scalar soll laut Herausgebern die bekanntesten Probleme anpacken, die beim Verwalten besonders großer Repositories regelmäßig auftauchen.

So kuratiert und konfiguriert es ein Featureset mit eingebautem Dateisystem-Monitor, Multipack-Index, Diagrammen zu geleisteten und erhaltenen Commits und einen Überblick geplanter Wartungsarbeiten. Zudem bietet Scalar Möglichkeiten zu gezieltem, auch partiellem Klonen und soll mit einer neuen Technik namens Sparse Checkout (zu deutsch etwa "Auschecken im Sparmodus") große Monorepos in der Handhabung kleiner erscheinen lassen.

Repositories klonen und Referenzen aktualisieren mit Scalar

Mit Scalar lassen sich Repositories relativ einfach klonen durch folgenden Befehl: $ scalar clone /path/to/repo. Auch das Klonen ganzer Repositories ist durch die Option --full-clone damit möglich. Um die für Scalar empfohlene Standardkonfiguration auf einen schon vorhandenen Klon anzuwenden, genügt der folgende Code:

$ cd /path/to/repo
$ scalar register

Eine weitere Neuerung betrifft das Verwalten mehrerer Zweige, die gemeinsam ein größeres Feature begründen. Beim Bearbeiten großer Features kann es hilfreich sein, die Arbeit auf mehrere separate Zweige herunterzubrechen, die jeweils aufeinander aufbauen. Sobald Developer jedoch frühere Zweige bearbeiten, kann das Verwalten der Versionsgeschichte für ein git rebasemühsam werden. Dafür bietet Git 2.38 eine Option namens --update-refs.

Wer regelmäßig das Rebase so durchführen will, kann durch die Konfiguration git config --global rebase.updateRefs true Git dazu anweisen, die Option --update-refs automatisch zu verwenden.

Sparmodus zum Verringern der Repositorygröße

Die Idee des Sparmodus zum Verringern der Repositorygröße ist nicht neu, hierzu hatten Git-Entwickler Anfang 2020 bereits einen längeren Blogpost mit Anleitungen und Erklärungen hinterlegt ("Bring your monorepo down to size"). Darin ist auch das nun in Scalar eingebettete kegelförmige Pattern zur Performancesteigerung im Sparmodus beschrieben. Damals liefen die Arbeiten an der Entwicklung eines sparse-checkout-Befehls noch und es war mehr Handarbeit nötig als mittlerweile. Der Trick beim Sparmodus besteht wohl darin, dass Git damit weniger einzelne Dateien inspizieren muss, wenn Entwickler Befehle wie git add, git status oder git checkout ausführen.

Ein Cone Mode soll dem Feature weiteres Skalieren für besonders große Repositories ermöglichen. Dafür kommen Techniken des Pattern-Matching zur Anwendung, die der Logik von .gitignore folgen. Die Dateien listen Muster auf. Beginnt eine Zeile mit !, werden die Pfade, die diesem Muster entsprechen, von der weiteren Auswertung ausgeklammert. Damit lässt sich der Vorgang des Abgleichens beschleunigen, da nur mehr Ordner mit Patterns ohne das Rufzeichen zu matchen sind. Allerdings kann das in der Praxis wohl recht komplex werden, wenn es um das Spezifizieren komplizierter Patterns geht. Große Repositories benötigen möglicherweise Tausende von Patterns, um ein Arbeitsverzeichnis zu beschreiben, und die Überprüfung jedes Musters mit Millionen von Pfaden würde zu Milliarden von Musterprüfungen bei jedem Git-Checkout-Befehl führen. Das kann sehr lange dauern.

Unter der Haube: Sparse Checkout in Scalar

Die meisten Git-Nutzer können stattdessen auf einen einfacheren Mechanismus zurückgreifen, indem sie lediglich Einschränkungen berücksichtigen, die auf dem Matchen der Dateiordner-Präfixe beruhen. Die Sparse-Checkout-Datei kann dann danach vorgehen, ob ein Muster rekursiv ist oder ein Parent Pattern, was den Ablauf beschleunigt. Git erzeugt beim Parsen der Patterns nämlich zwei unterschiedliche Hashsets für rekursive und Eltern-Pfade. Rekursive Datensätze werden dadurch automatisch ihren Eltern-Pfaden zugeschlagen. Eine detaillierte Erläuterung zum zugrundeliegenden Code findet sich auf GitHub. Im Blogeintrag steht eine Anleitung zum Klonen von Repositories im Sparse-Modus. Die Konfigurationsmöglichkeiten befinden sich laut Entwicklerteam zurzeit noch im experimentellen Status.

Der Rest vom Eisberg in den Release Notes

Zeitlich fiel das aktuelle Release mit dem von Google ausgerichteteten Summer of Code zusammen, an dem Git teilnahm. Das Projekt betreuten in diesem Rahmen zwei Studierende, die sich mit Sparse-Index-Integration und Erreichbarkeits-Bitmaps befassten. Ihre Arbeiten sind in Git 2.38 eingeflossen, wie sich im Detail im Blogpost-Abschnitt "Tidbits" nachlesen lässt.

Interessierte finden eine vollständige Liste der Änderungen in den Release Notes auf GitHub. Ergänzend ist eine Ankündigung im GitHub-Blog erschienen, die die wesentlichen Änderungen ausführlich vorstellt.

(sih)