Итак, общий репозиторий git, похоже, более или менее идеален для синхронизации папок с большими BLOB-объектами. У меня есть около 700 ГБ фотографий и видео, которые я хочу распространить по своим компьютерам, но использование git без каких-либо других дополнений приводит к огромным издержкам на использование диска, что на самом деле не нужно.
Теперь клонирование с --shared (или -s) дает мне репозиторий git без локального хранилища объектов (если я правильно понял), что, в общем-то, мне и нужно. Однако документация начинается со слов "Когда клонируемый репозиторий находится на локальной машине...". clone -s работает так же хорошо через SSH, но это заставляет меня задуматься, что произойдет, если клонируемый репозиторий будетнетна локальной машине. Поскольку документация -s начинается с этого предложения, мне кажется, что весь этот случай не охвачен. Нужно ли мне следить за чем-то, кроме удаления коммитов на удаленной стороне, что может привести к тому, что определенные объекты (которые все еще могут использоваться локально) будут удалены сборщиком мусора? (чего в любом случае не произойдет, так как я хочу использовать пустые репозитории на сервере)
решение1
Мне нравится git, но, к сожалению, git не является подходящим инструментом для этой задачи.
Git был разработан для очень эффективного сохранения истории изменений для репозиториев с текстовым контентом. Хотя git поддерживает сохранение двоичных файлов, ему придется хранить их в истории вечно, чтобы вы могли переключиться на любую ревизию, что очень затратно с точки зрения дискового пространства.
Также, предполагая, что ваши двоичные файлы не сжимаются (фотографии, фильмы, музыка и т. д.), размер хранилища объектов git будет примерно таким же, как и у tree checkout. Другими словами, для 700 ГБ исходных файлов хранилище объектов ( .gitкаталог) будет потреблять примерно столько же, а затем больше, когда вы начнете коммитить — добавлять и удалять контент.
Вы можете использовать так называемый неглубокий клон, который сохраняет только последнюю ревизию объекта в хранилище объектов, но неглубокие репозитории можно только клонировать, но не коммитить. В этом случае главный репозиторий git должен быть нормальным (не неглубоким) и все еще большим, однако все неглубокие клоны будут разумного размера.
Вам, вероятно, будет лучше, если вы сохраните более простую схему синхронизации, например rsync. Однако в этом случае вы потеряете возможность просматривать историю — бесплатного обеда не бывает :(
решение2
Я понимаю, что это не совсем ответ на ваш вопрос, но... разве не так?rsyncбыло бы намного проще синхронизировать две папки?