Ich studiere durch man gitglossaryund dieser eine Begriff ist mir entgangen – weil er im Glossar überhaupt nicht definiert ist.
Es wird nur zweimal darauf verwiesen (Sternchen hinzugefügt):
alternate object database
Via the **alternates mechanism**, a repository can inherit part of its
object database from another object database, which is called
"alternate".
repository
A collection of refs together with an object database containing
all objects which are reachable from the refs, possibly accompanied
by meta data from one or more porcelains. A repository can share an
object database with other repositories via **alternates mechanism**.
Was ist der “alternative Mechanismus”, auf den hier Bezug genommen wird?
Die kurze Antwort ist, dass Sie jedes vorhandene Git-Repository auf eine beliebige Anzahl von verweisen können zusätzlich bestehenden Git-Repositories – insbesondere zu ihren .git/objects Verzeichnisse – danach sucht Ihr Git nach Objekten in Ihren eigenen .git/objects Verzeichnis und alle anderen aufgelisteten (in der Reihenfolge der Auflistung).
Was schwieriger zu beschreiben ist, ist warum Vielleicht möchten Sie dies tun.
Es hilft, wenn Sie wissen, wie git intern funktioniert. In Git lösen sich Bezeichner in der Regel ziemlich schnell in ihre Hash-ID auf:
Git sucht dann nach dem Objekt, das dieser ID entspricht. In diesem Fall ist das Objekt ein Commit. Wenn Ihr Ziel darin besteht, etwas mit dem Commit zu tun – es beispielsweise auszuchecken oder es mit einem anderen Commit zu vergleichen – liest git das Objekt, das die ID eines Baums enthält. Git liest dann das Baumobjekt; Dies enthält die Namen zusätzlicher Bäume und Dateien (“Blobs”) und ihre IDs, und git liest diese Objekte, um die Dateien und rekursiv die Unterbäume und ihre Dateien zu finden.
Nehmen wir nun an, Sie haben eine vorhandene Kopie eines sehr großen Projektarchivs und möchten es – aus welchen Gründen auch immer – erneut klonen (vielleicht um einen separaten Klon für die Arbeit in einem separaten Zweig zu haben).1 Anstatt eine zweite vollständige Kopie des ursprünglichen Repositorys zu erstellen, können Sie git mitteilen, dass alle ursprünglichen Objekte in der verfügbar sind Erste Repository. Sobald git den alternatives-Eintrag hat, kann es diese Objekte finden und muss sie nicht herunterladen.
Neue Objekte, die Sie in diesem zweiten Klon erstellen, werden natürlich einfach in den zweiten Klon eingefügt; aber das spart viel Zeit und Platz.
(“Gemeinsam genutzte” Klone auf einer einzelnen Maschine verlinken im Allgemeinen direkt zu den Objekten des anderen Klons, indem sie harte Links im Unix-Stil verwenden, aber wenn dies nicht möglich ist, bietet der alternative Mechanismus eine andere Möglichkeit, dasselbe zu tun. Die Gefahr bei alternativen ist das Wenn der erste Klon entfernt wird, verschwinden die Objekte; harte Links haben diesen Fehler nicht. A --reference Klon verwendet auch den alternativen Mechanismus.)
Wie für:
Wo ist die offizielle Dokumentation, die es definiert?
Die beste Antwort ist wahrscheinlich “in der Quelle”. 🙂
1Jetzt, da Git die Möglichkeit hat, mehrere Arbeitsbäume von einem einzigen Klon bereitzustellen, ist dies weniger wichtig als früher.
Ich habe eine Antwort hinzugefügt, um den Teil “in der Quelle” abzudecken;) +1 natürlich auf Ihre Antwort.
– VonC
21. März 2016 um 8:00 Uhr
Danke für diese brillante und gründliche Antwort auf diese knifflige Frage von mir. 🙂 Ich habe noch eine, die Sie vielleicht ausprobieren möchten: stackoverflow.com/q/62497089/5419599
– Platzhalter
21. Juni 2020 um 10:13 Uhr
Sieht so aus, als wäre VonC viel schneller dazu gekommen als ich. 🙂
– Torek
21. Juni 2020 um 21:00 Uhr
VonC
In Bezug auf Git selbst wurde die erste Erwähnung eines „alternativen Objektdatenbankspeicherorts“ vorgenommen ace1534 begehen (Mai 2005, git v0.99)
Führen Sie SHA1_FILE_DIRECTORIES ein, um mehrere Objektdatenbanken zu unterstützen.
SHA1_FILE_DIRECTORIES Die Umgebungsvariable ist ein durch Doppelpunkte getrennter Pfad, der verwendet wird, wenn nach SHA1-Dateien gesucht wird, die nicht an der üblichen Stelle zum Lesen gefunden werden. Beim Erstellen einer neuen SHA1-Datei wird dieser alternative Speicherortmechanismus für die Objektdatenbank nicht verwendet. Dies ist nützlich, um ältere, selten verwendete Objekte in separaten Verzeichnissen zu archivieren.
Das war ein erstes Beispiel, das schnell aus Git entfernt wurde (im September 2005 a9ab586 begehen)
Bereiten Sie eine alternative Objektdatenbankregistrierung vor.
Die Variable alt_odb_list Punkte auf der Liste der struct alternate_object_database.
Die Elemente auf dieser Liste stammen von nicht leeren Elementen, die durch Doppelpunkte getrennt sind ALTERNATE_DB_ENVIRONMENT Umgebungsvariable und GIT_OBJECT_DIRECTORY/info/alternatesderen Inhalt genau das gleiche Format wie diese Umgebungsvariable hat.
Seine Basis zeigt auf einen statisch zugewiesenen Puffer, der “/the/directory/corresponding/to/.git/objects/...“, während sein Name direkt nach dem Schrägstrich am Ende von “.git/objects/” im obigen Beispiel und hat genug Platz, um 40-Byte-Hex-SHA1, einen zusätzlichen Schrägstrich für die Indirektion der ersten Ebene und die abschließende NUL aufzunehmen.
Das ist wahrscheinlich die genaueste Definition des “alternativen Mechanismus”, die Sie in Git-Quellen finden können.
Es gibt nur zwei Hauptstrukturen im Herzen eines Git-Repos, auf denen alles basiert: Da ist die Objektdatenbank und da ist die Referenzdatenbank.
In der Objektdatenbank werden alle Daten gespeichert. Der Inhalt aller Dateien, die Verzeichnisstrukturen, die Commits, alles, geht in die Objektdatenbank. Jedoch, Das Bemerkenswerte an der Objektdatenbank ist, dass sie im Wesentlichen nichts anderes als ein Schlüsselwertspeicher ist.
Git speichert Daten in der Objektdatenbank unter Verwendung eines Hash-basierten Abrufs, was bedeutet, dass die Schlüssel des Speichers die (SHA1)-Hashes der Werte sind.
Das hat einige interessante weitere Implikationen: Die Werte in der Objektdatenbank sind im Wesentlichen unveränderlich und Sie benötigen keinen Aktualisierungsvorgang.
Anstatt die Objektdatenbank und die Ref-Datenbank so zu speichern, wie es Git normalerweise tut – in flachen Dateien – können Sie Ihre eigene Backend-Implementierung bereitstellen und tun, was Sie wollen.
Git unterstützt traditionell:
odb_loose implementiert das lose Dateiformat-Backend. Es greift auf jedes Objekt in einer separaten Datei im Objektverzeichnis zu, wobei der Name jeder Datei dem SHA1-Hash ihres Inhalts entspricht.
odb_pack implementiert das Packfile-Backend. Es greift auf die Objekte in Git-Packfiles zu, einem Dateiformat, das sowohl zum platzsparenden Speichern von Objekten als auch zum Übertragen der Objekte beim Pushen oder Ziehen verwendet wird.
(siehe auch „Ist der git-Binär-Diff-Algorithmus (Delta-Storage) standardisiert?“)
11292400cookie-checkWas ist der „Alternativmechanismus“ von Git?yes
