Versionsverwaltung: Git 2.34 dünnt den Index aus

Inhaltsverzeichnis

Die Versionsverwaltungssoftware Git ist in Version 2.34 erschienen. Das Release bringt eine neue Indexarchitektur mit, die im Zusammenspiel mit Sparse-Checkouts und beim partiellen Klonen Performancevorteile bringen soll. Außerdem ist die bereits im Vorgänger vorbereitete neue Merge-Strategie ort an Bord, und Reachability Bitmaps sind nicht mehr zwingend an ein einzelnes Packfile gebunden.

Spärlich bestückter Index

Gerade für umfangreiche Monorepos bietet sich ein sparse-checkout an, um nur einen Teil des Repository auszuchecken und zu bearbeiten. Dabei lassen sich einzelne Verzeichnisse statt des gesamten Inhalts bearbeiten. Auch das partielle Klonen eines Repository über eine mit dem Parameter --filter gesetzte Filterspezifikation übernimmt nur einen Teil des Originals.

Bisher war in beiden Fällen die jeweilige Teilmenge immer noch stark mit dem gesamten Repository verbunden, da der Index sich auf dessen gesamten Umfang bezieht. Git 2.34 führt nun einen Sparse-Enabled Index ein, der nur die Teile des Teil-Repository enthält, die zum Sparse-Checkout gehören oder an der Grenze zwischen diesem und dem gesamten Repository stehen. Auf GitHub findet sich ein ausführlicher Blogbeitrag zu den technischen Details des Sparse-Enabled Index.

Dadurch entfällt der bisherige Overhead, den der vollständige Index mit sich brachte, da er jede Änderung über das gesamte Repository nachverfolgen musste, auch wenn sie keinerlei direkte Verbindung zu dem partiellen Klon beziehungsweise Sparse-Checkout hatte.

Angeblicher Zwilling

Die zweite große Neuerung warf bereits in der im August veröffentlichten Version 2.33 ihren Schatten voraus: Git setzt ab dem aktuellen Release beim Merge standardmäßig auf die Strategie ort statt wie bisher auf recursive. Der Name der neuen Strategie ist ein Akronym für Ostensibly recursive's Twin, also den augenscheinlichen Zwilling der rekursiven Strategie.

Die komplett neu geschriebene Umsetzung der Merge-Strategie setzt auf dieselben grundlegenden Konzepte wie recursive, soll aber zahlreiche Performanceprobleme des rekursiven Ansatzes vermeiden und gleichzeitig die Korrektheit verbessern. Im Gegensatz zu recursive arbeitet ort nicht auf dem Index. Außerdem hat die Community wohl beim Rewrite einige bekannte Bugs der alten Strategie behoben. Der alte Ansatz ließ sich zudem aufgrund der Historie nur umständlich erweitern und optimieren. Ursprünglich geht er auf ein Python-Skript zurück, das Plumbing Commands von Git verwendet.

Seine Stärke spielt der neue Ansatz laut einem Blogbeitrag zu Git 2.34 besonders dann aus, wenn der Merge mit vielen Namensänderungen verbunden ist. Der Beitrag spricht von einem Performancezuwachs bis zu einem Faktor 500. Für Extremfälle mit einer Reihe gleichartiger Merges beispielsweise bei einem Rebase kann der Performancegewinn wohl sogar über dem Faktor 9000 liegen. Abgesehen von den extremen Szenarien sollten alle Entwicklerinnen und Entwickler durch das Umstellen der Standardstrategie von einer moderat verbesserten Performance und vor allem weniger Fehlern bei Merges profitieren.

Erreichbarkeit, SSH und Tippfehler

Eine weitere Neuerung betrifft die Reachability Bitmaps, in denen Git speichert, wie einzelne Objekte der jeweiligen Commits erreichbar sind. Bisher waren die .bitmap-Dateien auf einzelne Packfiles begrenzt, da sie an die Anordnung der Objekte in einem Packfile gebunden waren. Git 2.34 führt ein neues Bitmap-Format ein, das einen Multi-Pack Index (MIDX) für die Arbeit mit mehreren Packfiles mitbringt.

Erwähnenswert ist zudem, dass Entwicklerinnen und Entwickler neuerdings SSH-Schlüssel statt PGP-Signaturen zum Signieren verwenden können. Schließlich gibt es eine neue Option für help.autoCorrect, die bestimmt, wie die Versionsverwaltung mit Tippfehlern wie git psuh umgeht. Neben den bisherigen Varianten never für keine Korrektur und einer Sekundenzahl oder immediate zum automatischen Korrigieren kennt Git 2.34 neuerdings die Option prompt, die interaktiv nachfragt, ob Git einen fehlgeschlagenen Befehl mit der vorgeschlagenen Korrektur erneut durchführen soll.

Die vollständige Liste der Änderungen in Git 2.34 findet sich in den Release Notes. Eine ausführliche Beschreibung der wichtigsten Neuerungen lässt sich einem Blogbeitrag auf GitHub entnehmen.

Siehe auch:

• Git: Download schnell und sicher von heise.de

(rme)