Versionsverwaltung Git 2.37: Unerreichbare Objekte und mehr

Inhaltsverzeichnis

Noch nicht einmal drei Monate sind vergangen, seitdem die Entwickler und Entwicklerinnen hinter der Versionsverwaltung Git die Version 2.36 veröffentlicht haben – nun stellen sie mit 2.37 bereits das nächste Release ihrer Software vor. Auch diese Version bietet eine ganze Reihe neuer Funktionen und Fehlerkorrekturen, die laut Aussagen des Teams mehr als 75 Mitwirkende beigetragen haben. Zu den Neuerungen gehören unter anderem eine Möglichkeit zum Umgang mit nicht erreichbaren Objekten, ein integrierter Dateisystem-Monitor für Windows und macOS sowie die Verfügbarkeit eines schon länger angekündigten Sparse-Index für den allgemeinen Einsatz.

Nicht erreichbare Objekte und deren Probleme

Unter Git gilt ein Objekt als erreichbar, wenn es mindestens einen Verweis (Zweig oder Tag) gibt, von dem aus die Programmiererin oder der Programmierer über die Objekte hinweggehen kann: von Commits zu deren Eltern, von Bäumen zu ihren Unterbäumen bis zum Ziel. Ein Objekt gilt als unerreichbar, wenn kein solcher Verweis existiert.

Ein Git-Repository benötigt all seine erreichbaren Objekte, um sicherzustellen, dass es intakt ist. Haben sich viele unerreichbare Objekte angehäuft und wird beispielsweise der Speicherplatz knapp, so erledigt Git dies automatisch beim Durchführen einer Garbage Collection. An dieser Stelle kommt die Konfiguration gc.pruneExpire ins Spiel: Sie definiert eine Gnadenfrist, während der unerreichbare Objekte, die noch nicht alt genug sind, um vollständig aus dem Repository entfernt zu werden, noch in Ruhe gelassen werden. Das soll verhindern, dass ein unerreichbares Objekt, das gelöscht werden soll, durch einen anderen Prozess (wie eine eingehende Referenzaktualisierung oder einen Push) erreichbar wird, bevor es wirklich gelöscht wird. Dadurch würde das Repository in einem korrupten Zustand zurückbleiben.

Wie richtig umgehen mit den Objekten?

Das Setzen einer kleinen, von Null abweichenden Schonfrist macht es unwahrscheinlicher, dass solch ein Wettlauf in der Praxis auftritt. Es führt jedoch zu einem weiteren Problem: Wie können Entwickler dann das Alter der unerreichbaren Objekte, die das Repository nicht verlassen haben, im Auge behalten? Sie können diese Objekte nicht in eine einzige Packdatei speichern: Da alle Objekte in einem Paket dieselbe Änderungszeit haben, zieht die Aktualisierung eines Objekts sie alle nach vorn. Vor Git 2.37 wurde stattdessen jedes "überlebende" unerreichbare Objekt als “loses Objekt“ (loose object) herausgeschrieben. Dabei wurde die mtime der einzelnen Objekte verwendet, um ihr Alter zu speichern. Dies kann jedoch zu ernsthaften Problemen führen, wenn es viele unerreichbare Objekte gibt, die zu neu sind und sich nicht beschneiden lassen.

Das Git-Team hat mit dem Release 2.37 nun ein neues Konzept eingeführt, die sogenannten cruft-packs. Sie ermöglichen es, unerreichbare Objekte zusammen in einer einzigen Packdatei zu speichern, indem die Altersangaben der einzelnen Objekte in eine Hilfstabelle geschrieben werden, die sich in einer *.mtimes-Datei neben dem Pack speichern lässt.

Integrierter Dateisystem-Monitor für Windows und macOS

Wer schon häufiger mit Git gearbeitet hat, kennt das Problem: Die Größe des Arbeitsverzeichnisses kann sich erheblich auf die Leistung von Git auswirken. Führt ein Programmierer oder eine Programmiererin beispielsweise git status aus, so muss Git (im schlimmsten Fall) das gesamte Arbeitsverzeichnis durchforsten, um herauszufinden, welche Dateien geändert wurden.

Git verfügt über eigene, zwischengespeicherte Informationen zum Dateisystem, um dieses Durchlaufen des gesamten Verzeichnisses in vielen Fällen zu vermeiden. Allerdings kann es Git belasten, sein zwischengespeichertes Wissen über das Dateisystem mit dem tatsächlichen Zustand der Festplatte zu aktualisieren, während die Programmierer aktiv arbeiten.

Schon bisher war es möglich, Tools wie Watchman über einen Hook in Git zu integrieren. Dadurch wurde der aufwendige Aktualisierungsprozess von Git durch einen lang laufenden Daemon ersetzt, der den Zustand des Dateisystems direkter verfolgt. Dieses Einrichten und die Installation eines Drittanbieterwerkzeugs wurde jedoch von vielen Nutzerinnen und Nutzern als mühsam empfunden. In Git 2.37 ist diese Funktion nun unter Windows und macOS in Git selbst integriert, sodass kein externes Tool installiert werden muss und auch das Konfigurieren des Hooks entfällt. Entwickler können das für Ihr Repository aktivieren, indem sie die Konfigurationseinstellung core.fsmonitor aktivieren.

$ git config core.fsmonitor true

Nach dem Einrichten der Konfiguration nimmt ein erster Git-Status zwar zunächst nicht weniger Zeit als zuvor in Anspruch, aber nachfolgende Befehle nutzen die überwachten Daten und sollten dann deutlich schneller ablaufen.

Sparse-Index für den allgemeinen Einsatz

Bereits im letzten Jahr hatte das Git-Team den sogenannten Sparse-Index angekündigt. Die Funktion soll eine Beschleunigung der Git-Befehle bewirken, wenn die Entwicklungsteams die Sparse-Checkout-Funktion einsetzen. Sie wird in der Regel bei sehr großen Repositories eingesetzt. Mit dem aktuellen Release steht die Sparse-Index nun allen entsprechenden Git-Subkommandos und damit auch allen Anwendern zur Verfügung. Ein ausführlicher Thread schildert alle Details zu den Änderungen und Integrationen in die Kommandos.

Und wer schon immer mal persönlich an den Lake Michigan reisen wollte: Das Entwicklerteam von Git kündigt in seinem Blog-Beitrag auch an, dass im September 2022 erstmals wieder die Konferenz Git Merge vor Ort in Chicago stattfinden wird. Das Einreichen von Themen und damit auch die Teilnahme mit einem Vortrag ist aktuell noch möglich.

Siehe auch:

• Git: Download schnell und sicher von heise.de

(fms)