Das Open-Source-Git-Projekt eben veröffentlichte Git 2.47 mit Funktionen und Fehlerbehebungen von über 83 Mitwirkenden, davon 28 neu. Das letzte Mal haben wir uns mit Ihnen über die neuesten Entwicklungen in Git unterhalten 2.46 wurde veröffentlicht.
Zur Feier dieser neuesten Version werfen wir hier einen Blick auf GitHub mit einigen der interessantesten Funktionen und Änderungen, die seit dem letzten Mal eingeführt wurden.
Inkrementelle Multipack-Indizes
Wiederkehrende Leser dieser Serie werden sich zweifellos an unsere Berichterstattung über alles rund um Multipack-Indizes (MIDXs) erinnern. Wenn Sie neu hier sind oder eine Auffrischung gebrauchen könnten, finden Sie hier eine kurze Zusammenfassung.
Git speichert Objekte (die Blobs, Bäume, Commits und Tags, aus denen der Inhalt Ihres Repositorys besteht) in einem von zwei Formaten: entweder lose oder gepackt. Lose Objekte sind die einzelnen Dateien, die in den zweistelligen Unterverzeichnissen von gespeichert sind $GIT_DIR/objectswobei jedes einen Splitter des gesamten Satzes loser Objekte darstellt. Zum Beispiel das Objekt 08103b9f2b6e7fbed517a7e268e4e371d84a9a10 würde lose gelagert werden $GIT_DIR/objects/08/103b9f2b6e7fbed517a7e268e4e371d84a9a10.
Objekte können auch in einer einzigen Datei zusammengefasst werden, die als a bezeichnet wird Packdatei. Packfiles speichern mehrere Objekte zusammen in einem Binärformat, was gegenüber der losen Speicherung von Objekten einige Vorteile bietet. Packfiles haben oft bessere Ergebnisse Cache-Lokalität weil ähnliche Gegenstände oft nebeneinander oder nahe beieinander verpackt sind. Packdateien haben außerdem den Vorteil, dass sie Objekte als Deltas voneinander darstellen können, was eine kompaktere Darstellung von Paaren ähnlicher Objekte ermöglicht.
Allerdings kann es bei Repositorys zu schlechter Leistung kommen, wenn sie viele Packdateien ansammeln, da Git jede Packdatei durchsuchen muss, um jede Objektsuche durchzuführen. Um die Leistung zu verbessern, wenn ein Repository zu viele Pakete ansammelt, muss ein Repository neu packen, um ein einzelnes neues Paket zu generieren, das den kombinierten Inhalt aller vorhandenen Pakete enthält. Dadurch verbleibt im Repository nur noch ein einziges Paket (was zu schnelleren Suchzeiten führt), aber die Kosten für die Generierung dieses Pakets können hoch sein.
In Git 2.21, Multipack-Indizes wurden eingeführt, um diesen Aufwand zu mindern. MIDXs sind eine Indexzuordnung zwischen Objekten zum Paket und der Position innerhalb dieses Pakets, an der sie erscheinen. Da MIDXs Informationen über Objekte über mehrere Pakete hinweg speichern können, ermöglichen sie eine schnelle Objektsuche für Repositorys, die viele einzelne Pakete enthalten, etwa so:
Hier wird der Multipack-Index als eine Reihe farbiger Rechtecke angezeigt, die jeweils ein Objekt darstellen. Die Pfeile zeigen auf die Position dieser Objekte innerhalb des Pakets, aus dem sie im MIDX ausgewählt wurden, und kodieren die im MIDX selbst gespeicherten Informationen.
Aber auch das Generieren und Aktualisieren des MIDX des Repositorys nimmt Zeit in Anspruch: Jedes Objekt in den Paketen, die Teil des MIDX sind, muss untersucht werden, um seine Objekt-ID und seinen Offset innerhalb seines Quellpakets aufzuzeichnen. Diese Zeit kann sich bei Verwendung sogar noch weiter ausdehnen Multipack-Erreichbarkeits-Bitmapsda es zur Laufzeit eine potenziell große Anzahl von Durchläufen hinzufügt, die erhebliche Teile des Repositorys abdecken.
Was gibt es also zu tun? Das Neupacken Ihres Repositorys zur Optimierung der Objektsuche kann langsam sein, das Gleiche gilt jedoch auch für die Aktualisierung des Multipack-Index Ihres Repositorys.
Git 2.47 führt eine neue experimentelle Funktion ein, die als inkrementelle Multipack-Indizes bekannt ist und es ermöglicht, mehr als einen Multipack-Index zusammen in einer Kette von MIDX-Ebenen zu speichern. Jede Ebene enthält Pakete und Objekte, die sich von früheren Ebenen unterscheiden, sodass der MIDX schnell über einen Anhängevorgang aktualisiert werden kann, der nur Zeit proportional zu den neu hinzugefügten Objekten benötigt, nicht jedoch zur Größe des gesamten MIDX. Hier ist ein Beispiel:
Die erste Hälfte der Abbildung ist dieselbe wie zuvor, die zweite Hälfte zeigt jedoch eine neue inkrementelle Ebene in der Multipack-Indexkette. Die im MIDX in der zweiten Hälfte enthaltenen Objekte sind einzigartig für die in der ersten Hälfte. Beachten Sie jedoch, dass die Quellpakete, die im MIDX in der zweiten Hälfte erscheinen, einige Überschneidungen mit den Objekten haben, die im MIDX in der ersten Hälfte erscheinen.
In Git 2.47 gilt die inkrementelle Multi-Pack-Indexfunktion noch als experimentell und unterstützt noch keine Multi-Pack-Erreichbarkeits-Bitmaps. Derzeit werden jedoch inkrementelle Multipack-Bitmaps unterstützt in Prüfung und wird hoffentlich in einer zukünftigen Version erscheinen.
(Bei GitHub planen wir, im Rahmen weiterer Skalierungsbemühungen inkrementelle Multi-Pack-Bitmaps zu verwenden, um noch größere Repositorys während der Repository-Wartung zu unterstützen. Wenn wir dies tun, erwarten wir von uns einen Blog-Beitrag mit den Details.)
Sie können mit inkrementellen Multipack-Indizes experimentieren, indem Sie Folgendes ausführen:
$ git multi-pack-index write --incremental
um noch heute neue Pakete zum vorhandenen MIDX Ihres Repositorys hinzuzufügen.
Git ist bekanntermaßen portabel und mit einer Vielzahl von Systemen und Architekturen kompatibel, darunter auch einige recht exotische. Aber bis zu dieser neuesten Version fehlte Git eine formelle Richtlinie zur Plattformunterstützung.
Diese Version enthält ein neues „Richtlinie zur Plattformunterstützung”-Dokument, das Gits offizielle Politik zu diesem Thema darlegt. Die genauen Details finden Sie im Quelllink unten, aber der aktuelle Kern ist, dass die Plattformen dies haben müssen C99 oder C11verwenden Sie Versionen von Abhängigkeiten, die stabil sind oder langfristige Unterstützung bieten und über ein aktives Sicherheitsunterstützungssystem verfügen müssen. Diskussionen über das Hinzufügen zusätzlicher Anforderungen, möglicherweise auch in Abhängigkeit von Rust in einer zukünftigen Version, sind im Gange.
Die Richtlinie enthält auch Vorschläge für Plattformbetreuer, welche Zweige getestet werden sollen und wie Kompatibilitätsprobleme gemeldet und behoben werden können.
Vor ein paar Veröffentlichungen, wir haben darüber gesprochen Gits vorläufige Unterstützung für ein neues Referenz-Backend namens nachrüstbar. Wenn Sie sich über die Details nicht im Klaren sind: Unser vorheriger Beitrag ist voll davon.
Diese Version bringt eine Reihe von Unit-Tests, die im benutzerdefinierten Test-Framework der Reftable-Implementierung geschrieben wurden, in das Standard-Unit-Test-Framework von Git. Diese Migrationen wurden von Chandra Pratap, einem der Git-Projekte, durchgeführt Mitwirkende des Google Summer of Code (GSoC)..
Mit dieser Version erhielt reftable auch eine bessere Unterstützung beim Umgang mit gleichzeitigen Autoren, insbesondere bei der Stapelkomprimierung. Das Reftable-Backend hat auch Unterstützung für die Option –exclude von git for-each-ref erhalten, über die wir geschrieben haben als Git 2.42 veröffentlicht wurde.
Während wir uns mit dem Thema Unit-Tests befassen, gab es eine Reihe anderer Bereiche des Projekts, die eine umfassendere Unit-Test-Abdeckung erhielten oder über vorhandene Tests aus der Shell-basierten Integrationstestsuite von Git migriert wurden.
Die Hashmap-API, das OID-Array und die URL-Match-Normalisierungsfunktionen von Git wurden alle von Shell-basierten Tests mit benutzerdefinierten Hilfsprogrammen in Komponententests umgewandelt. Auch das Unit-Test-Framework selbst erhielt große Aufmerksamkeit, was letztendlich zur Verwendung von führte Clar-Frameworkdas ursprünglich geschrieben wurde, um das Unit-Test-Framework in libgit2 zu ersetzen.
Viele dieser Unit-Test-Konvertierungen wurden von Ghanshyam Thakkar, einem weiteren Git-Mitarbeiter, durchgeführt GSoC-Mitwirkende. Herzlichen Glückwunsch, Ghanshyam!
Während wir uns mit den Mitwirkenden des Google Summer of Code befassen, sollten wir zu guter Letzt (aber nicht zuletzt!) einen weiteren Studenten erwähnen: shejialuoverbessert git fsck um zusätzlich zum regulären Objektspeicher auch das Referenzspeicher-Backend auf Integrität zu prüfen. Sie führten ein neues ein git refs verify Unterbefehl, der über ausgeführt wird git fsckund fängt viele Referenzkorruptionsprobleme ab.
Seit mindestens 2019wurde versucht, ungenutzte Parameter in Funktionen in der gesamten Git-Codebasis zu finden und zu kommentieren. Das Vermerken von Parametern als nicht verwendet kann dabei helfen, bessere APIs zu identifizieren, und oft kann das Vorhandensein eines nicht verwendeten Parameters auf einen legitimen Fehler in der Implementierung dieser Funktion hinweisen.
Seit vielen Jahren versucht das Git-Projekt, mit zu kompilieren -Wunused-parameter unter seinem Sonderangebot DEVELOPER=1 Modus, was es zu einem Kompilierzeitfehler macht, wenn in der gesamten Codebasis ungenutzte Parameter vorhanden sind oder eingeführt werden. In dieser Zeit gab es viele ungenutzte Parameterbereinigungen und Fehlerbehebungen, die alle unter Berücksichtigung anderer aktiver Entwicklungen in verwandten Bereichen durchgeführt wurden.
Mit dieser Veröffentlichung fanden diese Bemühungen ihren Abschluss. Jetzt beim Kompilieren mit DEVELOPER=1ist es jetzt ein Fehler bei der Kompilierung, ungenutzte Parameter zu haben, was die Codebasis von Git in Zukunft sauberer und sicherer macht.
Rückweg als Git 2.34 veröffentlicht wurdehaben wir über die wachsenden Bemühungen berichtet, Speicherlecks in der gesamten Git-Codebasis zu finden und zu beheben. Damals haben wir geschrieben, dass es aufgrund der typischerweise sehr kurzen Laufzeit von Git viel weniger dringend ist, Speicher freizugeben, als dies beispielsweise bei Bibliothekscode der Fall ist, da der Speicher eines Prozesses vom Betriebssystem „freigegeben“ wird, wenn der Prozess stoppt .
Da Git-Interna jedoch weiterhin umgestaltet werden, mit dem Ziel, sie als Erstanbieterbibliothek aufrufbar zu machen, ist das Schließen etwaiger Speicherlecks in der gesamten Codebasis von entscheidender Bedeutung.
Diese Bemühungen wurden in dieser Version fortgesetzt, wobei weitere Lecks in der gesamten Codebasis geschlossen wurden. Alle Einzelheiten finden Sie unter den folgenden Quellenlinks:
Der git mergetool Der Befehl hat eine neue Toolkonfiguration für Visual Studio Code gelernt. Während es war schon immer möglich Um Git manuell für die Ausführung der 3-Wege-Merge-Auflösung von VSCode zu konfigurieren, war eine manuelle Konfiguration erforderlich.
In Git 2.47 können Sie Ihr Repository jetzt einfach konfigurieren, indem Sie Folgendes ausführen:
$ git config set merge.tool vscode
und nachfolgende Ausführungen von git mergetool öffnen VSCode automatisch in der richtigen Konfiguration.
Dies ist nur eine Auswahl der Änderungen gegenüber der neuesten Version. Weitere Informationen finden Sie in den Versionshinweisen für 2.47oder jede frühere Version In das Git-Repository.
Geschrieben von
Taylor Blau ist Staff Software Engineer bei GitHub, wo er an Git arbeitet.
