Каковы последствия использования общего клона git, если исходный репозиторий удален?

501
Eadilu

Таким образом, общий репозиторий git кажется более или менее идеальным для синхронизации папок с большими каплями. У меня есть что-то вроде 700 ГБ картинок и видео, которые я хочу распределить по моим компьютерам, но использование git без каких-либо других дополнений приводит к огромным накладным расходам на использование диска, которые на самом деле не нужны.

Теперь, клонирование с --shared (или -s) дает мне репозиторий git без локального хранилища объектов (если я правильно понял), что в значительной степени то, что мне нужно. Однако документация начинается с «Когда репозиторий для клонирования находится на локальной машине ...». clone -s работает так же хорошо через SSH, но меня удивляет, что произойдет, если репозиторий для клона не находится на локальной машине. Поскольку документация -s начинается с этого предложения, я чувствую, что весь случай не охвачен. Есть ли что-то, за чем мне нужно следить, кроме удаления коммитов на удаленной стороне, которое может привести к тому, что определенные объекты (которые могут все еще использоваться локально) будут собираться? (что не произойдет в любом случае, так как я хочу использовать пустые репозитории на сервере)

0

2 ответа на вопрос

1
mvp

I love git, but unfortunately, git is not right tool for this task.

Git was designed to very efficiently keep change history for mostly text content repositories. While git does support keeping binaries, it will have to keep them forever in history so you can checkout to any revision, which is very expensive in terms of disk space.

Also, assuming that your binaries are not compressible (pictures, movies, music, etc), size of git object store will be about the same as tree checkout. In other words, for 700GB worth of original files, object store (.git directory) will consume about as much, and then more when you start committing - adding and removing content.

You can use so called shallow clone, which only keeps last revision of object in object store, but shallow repositories can be only cloned - not committed into. In this case, master git repository must be normal (not shallow) and will be still large, however all shallow clones will be reasonable size.

You probably will be better off by keeping simpler sync scheme like rsync. However, in that case you lose ability to review history - there is no free lunch :(

Извините, но, как я уже сказал, клон - Shared делает именно это. В отличие от мелкой копии, в хранилище объектов даже нет данных о пересмотре. Попробуйте ... Создайте git-репозиторий, поместите туда картинку и клонируйте ее с помощью git clone --shared. Папка .git будет небольшой, а хранилище объектов будет практически пустым. Обычно git предполагает (в этом состоянии), что вы можете просто получить доступ к объектам в исходном репозитории (отсюда, я полагаю, ограничение локальных операций в документации git). Просто я не могу найти информацию об общих клонах с нелокальным происхождением. Eadilu 10 лет назад 0
Обратите внимание, что общий клон имеет смысл, только если вы выполняете клонирование на одном компьютере - читайте документацию по git. Чтобы ваша ситуация клонировалась между компьютерами, вы должны использовать нормальные или мелкие клоны mvp 10 лет назад 0
Но это именно то, о чем я прошу ... Общая копия также "имеет смысл" для меня, потому что я не хочу, чтобы все эти объекты забивали мой жесткий диск. В документации git объясняется, как совместно используемые клоны работают локально, но git также создает общие клоны с удаленного компьютера. Нет никаких предупреждений или чего-либо еще, когда я клонирую общий репозиторий через ssh. Итак, я * прочитал * документацию. Я даже процитировал это в своем первоначальном вопросе. Это просто не покрывает мой случай. Eadilu 10 лет назад 0
Для работы репозитория git git необходим доступ к хранилищу объектов git, обычно хранящемуся в каталоге .git. Для локальных файлов разделяемый клон может обмануть и получить доступ к другому каталогу для хранилища объектов. Но для нелокальных файлов fs это просто не поддерживается git - он действительно хочет беспрепятственный локальный доступ к хранилищу объектов mvp 10 лет назад 0
Это просто неправда. Он поддерживается, как я уже говорил (по крайней мере, с точки зрения «работает ли он»): Git клонирует удаленные репозитории с опцией --shared - отлично. Я не спрашиваю * работает ли это *, я просто спрашиваю о последствиях: что мне нужно остерегаться, что может быть опасно и т. Д. Eadilu 10 лет назад 0
Вы думаете, что `--shared` работает, но на самом деле это не так. Обратите внимание, что `--shared` просто игнорируется для нелокального клона git - я только что проверил это на нескольких моих репозиториях, и на диске существует буквально * нет * разница между` git clone ssh: // server / repo` vs `git clone --shared ssh: // server / repo` mvp 10 лет назад 0
Я клонировал свои документы через ssh (с -s) дома в одночасье и сэкономил достаточно места на диске. Я не могу воспроизвести это здесь, что довольно странно - и поскольку я нахожусь в офисе, у меня не так много времени, чтобы проверить, почему это не работает. Тем не менее, монтирование удаленной папки ssh, клонирование (--shared) из этой подключенной папки, а затем повторная установка источника на адрес ssh, похоже, работает нормально. Опять же: какие проблемы могут возникнуть из-за этого? Проверка коммита, содержащего файлы, которых нет локально, кажется, работает нормально. Таким образом, у меня все еще будет общий клон с удаленным источником ... Eadilu 10 лет назад 0
Как именно вы "монтируете" папку ssh? Поскольку смонтированная файловая система (samba / NFS) считается локальной - вы обманываете себя. Это не работает так, как вы ожидаете mvp 10 лет назад 0
Я монтирую папку ssh через sshfs. Думаю, я просто оставлю это так. Если соединение прервано, git падает, но, кроме этого, я действительно не вижу никаких недостатков. Как это работает не так, как я ожидаю? Eadilu 10 лет назад 0
Вы думаете, что реплицируете git-репозиторий на нескольких машинах и невосприимчивы к любой конкретной ошибке коробки. Однако теперь вы действительно зависите от одного блока, в котором есть реальное хранилище объектов git, а все остальные блоки монтируют это хранилище объектов. Это создает единую точку отказа - если эта коробка не работает, ваш git-репозиторий исчезает. Вершина дерева будет присутствовать на всех других коробках, но история исчезнет mvp 10 лет назад 0
Нет, я * думаю *, что у меня есть хороший способ синхронизировать мои компьютеры. Мне известно о критическом состоянии хранилища в центре ... Конечно, я бы клонировал его хотя бы в одно другое место и синхронизировал эти хранилища. Однако этот способ кажется намного более безопасным, чем, например, unison или rsync, для синхронизации папок, поскольку все клиенты знают обо всех моментальных снимках, и все может быть отменено, если необходимо, - и коммиты могут быть описаны. Я * не могу * хранить всю историю всех моих фотографий на своих ноутбуках, места просто нет, но это, кажется, следующая лучшая вещь. Eadilu 10 лет назад 0
0
DoeNietZoMoeilijk

I realise that this is not really answering your question, but... wouldn't rsync be far easier to keep two folders in sync?

Две папки, да. Но у меня больше компьютеров, и я обычно прыгаю между настольным компьютером, ноутбуком, планшетом и рабочим компьютером, а у моей жены тоже есть собственный ноутбук. Кроме того, rsync не дает вам возможности добавлять сообщения коммитов, что приятно, потому что вы знаете, кто что сделал, и вы можете обвинить своих детей в удалении всех этих фотографий с прошлого отпуска ... и восстановить их. Eadilu 10 лет назад 0

Похожие вопросы