Was sind die Auswirkungen eines gemeinsam genutzten Git-Klons, wenn das Quell-Repository remote ist?


0

Daher scheint das gemeinsam genutzte Repository von a git mehr oder weniger perfekt zu sein, um Ordner mit großen Blobs synchron zu halten. Ich habe ungefähr 700 GB Bilder und Videos, die ich auf meinen Computern verteilen möchte, aber die Verwendung von git ohne weitere Zusätze führt zu einem enormen Speicherbedarf, der nicht wirklich benötigt wird.

Wenn ich jetzt mit --shared (oder -s) klone, bekomme ich 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 genauso gut über SSH, 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 ganze Fall nicht behandelt wird. Muss ich auf etwas anderes achten, als das Löschen von Commits auf der Remote-Seite, die dazu führen können, dass bestimmte Objekte (die möglicherweise noch lokal verwendet werden) über den Müll gesammelt werden? (was sowieso nicht passieren wird, da ich leere Repositorys auf dem Server verwenden möchte)

Antworten:


1

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

Git wurde entwickelt, um den Änderungsverlauf für die meisten Textinhalts-Repositorys sehr effizient zu verwalten. Zwar unterstützt git die Beibehaltung von Binärdateien, sie müssen jedoch für immer im Verlauf bleiben, damit Sie zu jeder Revision wechseln können, die im Hinblick auf den Speicherplatz sehr teuer ist.

Unter der Annahme, dass Ihre Binärdateien nicht komprimierbar sind (Bilder, Filme, Musik usw.), entspricht die Größe des Git-Objektspeichers in etwa der Größe des Baumauscheckvorgangs. Mit anderen Worten, für Originaldateien im Wert von 700 GB wird der Objektspeicher ( .gitVerzeichnis) ungefähr so ​​viel verbrauchen und dann mehr, wenn Sie mit dem Festschreiben beginnen - Hinzufügen und Entfernen von Inhalten.

Sie können den sogenannten flachen Klon verwenden, bei dem nur die letzte Revision des Objekts im Objektspeicher gespeichert wird. Flache Repositorys können jedoch nur geklont und nicht festgeschrieben werden. In diesem Fall muss das Master-Git-Repository normal (nicht flach) und immer noch groß sein. Alle flachen Klone haben jedoch eine angemessene Größe.

Sie werden wahrscheinlich besser dran sein, wenn Sie ein einfacheres Synchronisationsschema wie rsync beibehalten. In diesem Fall verlieren Sie jedoch die Fähigkeit, 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 enthält der Objektspeicher nicht einmal eine einzige Revision der Daten. Probieren Sie es aus ... Erstellen Sie ein Git-Repository, fügen Sie dort ein Bild ein und klonen Sie es über git clone --shared. Der .git-Ordner ist klein, und der Objektspeicher ist praktisch leer. Normalerweise geht git (in diesem Zustand) davon aus, dass Sie einfach auf die Objekte im Quell-Repository zugreifen können (daher denke ich, dass die Beschränkung auf lokale Operationen in der git-Dokumentation). Ich kann nur keine Informationen zu freigegebenen Klonen mit nicht lokalem Ursprung finden.
Eadilu

Beachten Sie, dass das gemeinsame Klonen nur Sinn macht, wenn Sie das Klonen auf demselben Computer ausführen - lesen Sie die Git-Dokumentation. Damit Ihre Situation zwischen Computern klonen kann, müssen Sie normale oder flache Klone verwenden
MVP

Aber genau darum bitte ich Sie ... Eine gemeinsame Kopie "macht auch für mich Sinn", weil ich nicht möchte, dass all diese Objekte meine Festplatte verstopfen. In der Git-Dokumentation wird erklärt, wie freigegebene Klone lokal funktionieren. GIT erstellt jedoch auch freigegebene Klone von einer entfernten Stelle aus. Es gibt keine Warnungen oder ähnliches, wenn ich ein freigegebenes Repository über ssh klone. Also, ich habe die Dokumentation zu lesen. Ich habe es sogar in meiner ursprünglichen Frage zitiert. Es geht nur nicht um meinen Fall.
Eadilu

Damit das Git-Repository funktioniert, benötigt Git Zugriff auf den Git-Objektspeicher, der normalerweise im Git-Verzeichnis gespeichert ist. Für lokale fs kann ein freigegebener Klon ein anderes Verzeichnis für den Objektspeicher betrügen und darauf zugreifen. Aber für nicht-lokale fs wird das von git einfach nicht unterstützt - es möchte wirklich einen ungehinderten lokalen Zugriff auf den Objektspeicher
mvp

Das stimmt einfach nicht. Es wird, wie ich bereits sagte, unterstützt (zumindest in Bezug auf "Funktioniert es?"): Git klont Remote-Repositorys mit der Option --shared. Ich frage nicht, ob es funktioniert, ich frage nur nach den Auswirkungen: Was muss ich
beachten

0

Mir ist klar, dass dies Ihre Frage nicht wirklich beantwortet, aber ... wäre es nicht viel einfacher, zwei Ordner mit rsync synchron zu halten?


Zwei Ordner, ja. Aber ich habe mehr Computer in der Nähe. Normalerweise wechsle ich zwischen Desktop, Laptop, Tablet und Arbeitsplatz-PC, und meine Frau hat auch einen eigenen Laptop. Außerdem bietet rsync nicht die Möglichkeit, Commit-Nachrichten hinzuzufügen. Dies ist hilfreich, da Sie wissen, wer was getan hat, und Ihre Kinder für das Löschen all dieser Bilder aus dem letzten Urlaub beschuldigen können. Und sie wiederherstellen.
Eadilu
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.