Was bedeutet ein gemeinsam genutzter Git-Klon, wenn das Quell-Repository entfernt ist?

560
Eadilu

Das gemeinsam genutzte a git-Repository scheint also mehr oder weniger perfekt zu sein, um Ordner mit großen Blobs synchron zu halten. Ich habe etwa 700 GB an Bildern und Videos, die ich auf meinen Computern verteilen möchte. Die Verwendung von git ohne weitere Zusätze führt jedoch zu einem erheblichen Festplattenverbrauch, der nicht unbedingt erforderlich ist.

Nun, beim Klonen mit --shared (oder -s) erhalten Sie ein Git-Repository ohne lokalen Objektspeicher (wenn ich das richtig verstanden habe), was ziemlich genau das ist, was ich brauche. Die Dokumentation beginnt jedoch mit "Wenn sich das zu klonende Repository auf dem lokalen Computer befindet ...". clone -s funktioniert über SSH genauso gut, aber ich frage mich, was passiert, wenn sich das zu klonende Repository nicht auf dem lokalen Computer befindet. Da die Dokumentation von -s mit diesem Satz beginnt, habe ich das Gefühl, dass der gesamte Fall nicht abgedeckt ist. Gibt es etwas, auf das ich achten muss, außer auf der entfernten Seite Commits zu löschen, die dazu führen könnten, dass bestimmte Objekte (die noch lokal verwendet werden) Müll gesammelt wird? (was sowieso nicht passieren wird, da ich nackte Repositorys auf dem Server verwenden möchte)

0

2 Antworten auf die Frage

1
mvp

Ich liebe git, aber leider ist git nicht das richtige Werkzeug für diese Aufgabe.

Git wurde entwickelt, um den Änderungsverlauf für hauptsächlich Textinhalt-Repositorys sehr effizient zu verwalten. Git unterstützt zwar das Beibehalten von Binärdateien, muss sie jedoch für immer in der Historie aufbewahren, damit Sie jede Revision überprüfen können, was in Bezug auf den Festplattenspeicher sehr teuer ist.

Wenn Sie davon ausgehen, dass Ihre Binärdateien nicht komprimierbar sind (Bilder, Filme, Musik usw.), entspricht die Größe des git-Objektspeichers ungefähr der Baumprüfung. Mit anderen Worten: Für 700 GB an Originaldateien .gitverbraucht der Objektspeicher ( Verzeichnis) ungefähr so ​​viel und dann mehr, wenn Sie mit dem Festschreiben beginnen - indem Sie Inhalte hinzufügen und entfernen.

Sie können einen sogenannten flachen Klon verwenden, der nur die letzte Revision des Objekts im Objektspeicher enthält, aber flache Repositorys können nur geklont werden, ohne dass ein Commit ausgeführt wird. In diesem Fall muss das Master-Git-Repository normal (nicht flach) sein und ist immer noch groß, jedoch haben alle flachen Klone eine angemessene Größe.

Sie werden wahrscheinlich besser sein, wenn Sie ein einfacheres Synchronisationsschema wie rsync verwenden. In diesem Fall verlieren Sie jedoch die Möglichkeit, den Verlauf zu überprüfen - es gibt kein kostenloses Mittagessen :(

Sorry, aber wie gesagt, clone --shared macht genau das. Im Gegensatz zu einer flachen Kopie hat es nicht einmal eine einzige Revision von Daten in seinem Objektspeicher. Probieren Sie es aus ... Erstellen Sie ein Git-Repository, fügen Sie dort ein Bild ein und klonen Sie es über Git-Klon --shared. Der .git-Ordner ist klein, der Objektspeicher ist praktisch leer. Normalerweise nimmt git an (in diesem Zustand), dass Sie einfach auf die Objekte im Quell-Repository zugreifen können (daher denke ich, die Einschränkung auf lokale Operationen in der git-Dokumentation). Es ist nur so, dass ich keine Informationen zu gemeinsam genutzten Klonen mit nicht lokalem Ursprung finden kann. Eadilu vor 9 Jahren 0
Beachten Sie, dass Shared Clone nur dann sinnvoll ist, wenn Sie auf demselben Computer Klonen ausführen. Lesen Sie dazu die Git-Dokumentation. Damit Ihre Situation zwischen Computern klonen kann, müssen Sie normale oder flache Klone verwenden mvp vor 9 Jahren 0
Aber genau das verlange ich ... Eine gemeinsame Kopie ist auch für mich "sinnvoll", weil ich nicht will, dass all diese Objekte meine Festplatte verstopfen. Die git-Dokumentation erklärt, wie Shared Clones lokal arbeiten - aber git erstellt Shared Clones auch von einer Remote-Station aus. Es gibt keine Warnungen oder ähnliches, wenn ich ein gemeinsam genutztes Repository über ssh klone. Also habe ich die Dokumentation * gelesen *. Ich habe es sogar in meiner ursprünglichen Frage zitiert. Es behandelt meinen Fall einfach nicht. Eadilu vor 9 Jahren 0
Damit git-Repository funktioniert, benötigt git Zugriff auf den git-Objektspeicher, der normalerweise im .git-Verzeichnis gespeichert ist. Für lokale Fs kann Shared Clone auf ein anderes Verzeichnis für den Objektspeicher zugreifen und darauf zugreifen. Aber für nicht-lokale fs wird das von git einfach nicht unterstützt - es will wirklich einen ungehinderten lokalen Zugriff auf den Objektspeicher mvp vor 9 Jahren 0
Das stimmt einfach nicht. Es wird unterstützt, wie ich bereits gesagt habe (zumindest in Bezug auf "funktioniert es"): Git klont Remote-Repositories mit der Option --shared. Ich frage nicht * ob * es funktioniert, ich frage nur nach den Implikationen: Worauf muss ich achten, was gefährlich sein kann usw. Eadilu vor 9 Jahren 0
Sie meinen, dass --shared funktioniert, aber das funktioniert wirklich nicht. Beachten Sie, dass "--shared" für nichtlokalen Git-Klon einfach ignoriert wird. Ich habe dies nur in einigen meiner Repositorys überprüft, und es gibt buchstäblich keinen Diskettenunterschied zwischen "git clone ssh: // server / repo" vs `git clone --shared ssh: // server / repo` mvp vor 9 Jahren 0
Ich habe meine Dokumente über ssh (with -s) über Nacht zu Hause geklont und dabei etwas Speicherplatz gespart. Ich kann es hier nicht reproduzieren, was wirklich komisch ist - und da ich im Büro bin, habe ich nicht viel Zeit, um herauszufinden, warum es nicht funktioniert. Das Mounten eines Remote-SSH-Ordners, das Klonen (--shared) aus diesem eingehängten Ordner und das anschließende Zurücksetzen des Ursprungs auf die SSH-Adresse scheint jedoch gut zu funktionieren. Nochmals: Welche Probleme könnten sich daraus ergeben? Das Auschecken eines Commits, das Dateien enthält, die lokal nicht vorhanden sind, scheint gut zu funktionieren. Auf diese Weise hätte ich immer noch einen gemeinsam genutzten Klon mit einem entfernten Ursprung ... Eadilu vor 9 Jahren 0
Wie genau "mounten" Sie den ssh-Ordner? Da das gemountete Dateisystem (Samba / NFS) als lokal betrachtet wird, täuschen Sie sich. Es funktioniert NICHT so, wie Sie es erwarten mvp vor 9 Jahren 0
Ich mounte einen ssh-Ordner über sshfs. Ich denke, ich lass es einfach so. Wenn die Verbindung unterbrochen wird, stürzt git ab, ansonsten sehe ich wirklich keine Nachteile. Wie funktioniert es nicht so, wie ich es erwartet habe? Eadilu vor 9 Jahren 0
Sie denken, Sie replizieren git-Repository auf mehreren Computern und sind immun gegen einen gegebenen Box-Fehler. Sie sind jedoch jetzt wirklich auf eine Box angewiesen, die über einen echten git-Objektspeicher verfügt, und alle anderen Boxen laden diesen Objektspeicher auf. Dadurch wird ein einzelner Fehlerpunkt geschaffen - wenn diese Box fehlschlägt, ist Ihr Git-Repository verschwunden. Der obere Teil des Baums wird auf allen anderen Feldern vorhanden sein, aber die Geschichte wird verschwunden sein mvp vor 9 Jahren 0
Nein, ich glaube, ich habe eine schöne Möglichkeit, meine Computer synchron zu halten. Ich bin mir des kritischen Status des Repositorys in der Zentrale bewusst ... Natürlich würde ich es an mindestens einem anderen Ort klonen und diese Repositorys synchron halten. Dieser Weg scheint jedoch viel sicherer zu sein als z. B. unison oder rsync, um Ordner synchron zu halten, da alle Clients alle Momentaufnahmen kennen und alles bei Bedarf rückgängig gemacht werden kann - und Commits beschrieben werden können. Ich kann * nicht * die gesamte Geschichte meiner Bilder auf meinen Laptops aufbewahren, der Raum ist einfach nicht vorhanden - aber dies scheint das nächstbeste zu sein. Eadilu vor 9 Jahren 0
0
DoeNietZoMoeilijk

Mir ist klar, dass dies nicht wirklich eine Antwort auf Ihre Frage ist, aber ... wäre Rsync nicht viel einfacher, zwei Ordner synchron zu halten?

Zwei Ordner, ja. Aber ich habe mehr Computer in der Nähe, wobei ich normalerweise zwischen Desktop, Laptop, Tablet und Work-PC springt und meine Frau auch ihren eigenen Laptop hat. Außerdem gibt Ihnen rsync keine Gelegenheit, Commit-Nachrichten hinzuzufügen. Das ist schön, weil Sie wissen, wer was getan hat, und Sie können Ihre Kinder dafür verantwortlich machen, dass sie all diese Bilder aus dem letzten Urlaub gelöscht haben ... und sie wiederherstellen. Eadilu vor 9 Jahren 0

Verwandte Probleme