Wie kann ich sicherstellen, dass ich beim Klonen, Synchronisieren und Abrufen von Inhalten aus einem anderen Git-Annex-Repository ein identisches Spiegelbild eingerichtet habe?
Ich habe in der Vergangenheit ein Tool wie Unison verwendet, das einen Datei-zu-Datei-Vergleich durchgeführt hat, aber das ist zeit- und speicherintensiv.
Gibt es andere Alternativen, mit denen ich eine Plausibilitätsprüfung durchführen kann? Der Hauptgrund dafür ist, dass ich gerade einen Klon eines vorhandenen Repositorys erstellt habe, der kleiner ist. Ich gehe davon aus, dass es kleiner ist, da das alte Repository unbenutzte oder nicht referenzierte Objekte enthält, aber die Größe ist ziemlich unterschiedlich.
Ich hätte also gerne eine Prüfung, die ich durchführen kann.
Antwort1
Git verfügt über eine integrierte Plausibilitätsprüfung ( git fsck), die auf allgemeine Probleme mit der Git-Metadatenstruktur hinweist. Außerdem gibt es einen Garbage Collector ( git gc), der unzusammenhängende Elemente und andere überflüssige Dinge entfernt.
Was die Datenintegrität betrifft … im Grunde ist dies eine Garantie, die Git bietet: Die Daten, die Sie eingeben, sind die Daten git log, die Sie herausbekommen. Wenn die (oder auch nur der Hash des letzten Commits) identisch sind, sind es auch die Daten. Jeder Schritt in Git wird anhand der Daten, Metadaten und des Vorherigen mit einer Prüfsumme verglichen; es ist so etwas wie eine Blockchain: Wenn sich die Daten irgendwo ändern, ändern sich auch die Prüfsummen. Wenn die Prüfsummen nicht übereinstimmen, beschwert sich Git beim Checkout sehr stark.
Es gibt einen alten (2007-2008?) Vortrag von Linus Torvalds über Git, den Sie auf Youtube ansehen können. Soweit ich mich erinnere, spricht er dort auch über die Datenintegrität. Hier gibt es auch einige Dokumentationen:https://git-scm.com/book/en/Git-Internals-Git-Objects
In der Praxis machen sich die Leute darüber keine Gedanken, da Git sich wie von Zauberhand darum kümmert. Sie führen einfach „git status“ aus, um zu sehen, ob Sie Änderungen pullen/pushen/commiten müssen, um mit dem Ursprung Schritt zu halten.
Zusätzlicher Speicherplatzbedarf kann auch andere Gründe haben ... git stashkann ein Platzfresser sein, wenn Sie ihn jemals genutzt haben.
Hier gibt es auch Unterschiede zwischen geklonten Repositories: Git kümmert sich nicht um lokale Inhalte, die nie festgeschrieben wurden. Wenn sie nicht festgeschrieben wurden, existieren sie für die Klone nicht.
Antwort2
Ich habe wie folgt überprüft, ob Git Annex wie erwartet funktioniert:
- Holen Sie sich eine sortierte, eindeutige Dateiliste inklusive .git-Inhalten (dadurch wird sichergestellt, dass wir über alle Inhalte der Git-Anhänge verfügen)
- Erhalten Sie eine sortierte, eindeutige Linkliste einschließlich .git-Inhalten (dies stellt sicher, dass wir die gleiche Repository-Struktur haben)
- Dateilisten vergleichen, Anhang/Übertragungsverzeichnis ignorieren, Git-Objekte können unterschiedlich sein, Git-Anhangsinhalte sollten identisch sein
- Linklisten vergleichen, sollten identisch sein
- Führen Sie ein „git annex fsck“ aus oder vergleichen Sie die Prüfsumme aller Dateien (dies ist ein Dateisystemproblem).
Dies funktioniert, kann aber etwas arbeits- und zeitintensiv sein. Darüber hinaus kann der Vorgang noch komplizierter werden, wenn Spiegel vorhanden sind, die nur Teilkopien sind. Bei diesen Spiegeln müssen Sie nur den Inhalt vergleichen, den Sie erwarten.