Каковы различия между git clone --shared и --reference?

После прочтения документации я до сих пор не понимаю, что различия между --shared и --reference <repo>. Они кажутся похожими.

  • Каковы различия между --shared и --reference <repo> параметры

  • Могут ли они использоваться для экономии места на диске при создании нескольких локальных клонов другой локальный клон?

  • Может ли каждый локальный клон иметь другую ветвь?

Примечание: Я знаю, что я могу использовать несколько мелких клонов с усеченными истории, используя git clone --depth <depth>, но каждый клон все еще должен дублируйте хотя бы некоторую историю, чтобы сделать это, поэтому я был думая, что, возможно, это не самый оптимальный способ сэкономить место на диске (хотя это лучше ничего).

Фон

Иногда мне нравится иметь более одной проверки моей рабочей копии в репозиторий, поэтому я создаю несколько клонов, где каждый клон имеет собственную проверку.

Однако мне не нужна вся история с каждым клоном, просто обновленные версии моих ветвей, поэтому я мог бы сэкономить много дисков чтобы каждый клон использовал теги, объекты фиксации, дерева и blob из оригинальный локальный клон (например, через символические ссылки для чего-то).

git clone документация

Я проверил документацию git clone, чтобы узнать, есть ли что-нибудь можно использовать.

--shared

Я видел, что есть опция --shared:

Когда репозиторий клонируется на локальном компьютере, вместо использования жесткого ссылки, автоматически настроить .git/objects/info/alternates для совместного использования объектов с исходным хранилищем. Результирующий репозиторий начинается без каких-либо объекта.

Похоже, что может быть полезным для того, чтобы помочь мне сэкономить место на диске с несколькими клонами, которые имеют разные проверки, поскольку каждый клон делится объекты с исходным локальным клоном.

--reference <repository>

Затем я также увидел параметр --reference <repository>:

Если ссылочный репозиторий находится на локальном компьютере, автоматически настройте .git/objects/info/alternates для получения объектов из ссылки репозиторий. Использование уже существующего репозитория в качестве альтернативы потребует меньше объектов, подлежащих копированию из клонирования клонирования, сокращение сети и локальные затраты на хранение.

ПРИМЕЧАНИЕ: см. ПРИМЕЧАНИЕ для параметра --shared.

Это говорит о том, что это сократит локальные расходы на хранение, поэтому это может быть полезно хорошо.

Ответы

Ответ 1

Оба варианта обновляют .git/objects/info/alternates, чтобы указать на исходный репозиторий, что может быть опасно, поэтому предупреждающая записка присутствует в обеих вариантах документации.

Параметр --shared не копирует объекты в клон. Это основное отличие.

В --reference используется дополнительный параметр репозитория. Использование --reference по-прежнему копирует объекты в пункт назначения во время клонирования, однако вы указываете, что объекты копируются из существующего источника, когда они уже доступны в ссылочном репозитории. Это может сократить время сети и IO из исходного репозитория путем передачи пути к репозиторию на более быстром/локальном устройстве с помощью --reference

Смотрите сами

Создайте клон --shared и клон --reference. Подсчитайте объекты в каждом, используя git count-objects -v. Вы заметите, что общий клон не имеет объектов, а ссылочный клон имеет такое же количество объектов, что и источник. Кроме того, обратите внимание на разницу в размерах в вашей файловой системе. Если вы должны переместить источник и протестировать git log в общих и ссылочных репозиториях, журнал недоступен в общем клоне, но отлично работает в клон-ссылке.

Ответ 2

Ссылка в комментариях к вашему вопросу на самом деле является более ясным ответом: --reference подразумевает --shared. Точка --reference заключается в оптимизации сетевого ввода-вывода во время первоначального клонирования удаленного репозитория.

В отличие от вышеприведенного ответа, я обнаружил, что репозитории --shared и --reference - из одного источника - имеют одинаковый размер и оба имеют нулевые объекты. Конечно, если вы используете --reference для некоторого другого репозитория, который основан на общем источнике, размер и объекты будут отражать разницу между репозиториями. Примечание, что в обоих случаях мы не сохраняем место в дереве работ, только .git/objects.

Существует несколько нюансов для продолжения этой настройки - прочитайте поток для более подробной информации. По сути, это похоже на то, что два следует рассматривать как публичные хранилища, с осторожностью переписывать историю при наличии переупаковки/обрезки/сборки мусора.

Рабочий процесс по поддержанию оптимального использования дискового пространства после начального клона выглядит следующим образом:

  • источник тяги
  • источник repack
  • вытянуть вторичный
  • git gc во вторичном

Вероятно, лучше всего прочитать обсуждение в этом потоке.

Вы можете добавить альтернативу существующим репозиториям, поместив абсолютный путь в исходный каталог objects в secondary/.git/objects/info/alternates и запустив git gc (многие используют git repack -a -d -l, что выполняется git gc).

Вы можете удалить альтернативу, запустив git repack -a -d (no -l) во вторичном, а затем удалив строку из файла alternates. Как описано в потоке, возможно иметь несколько альтернатив.

Я сам так не использовал, поэтому не знаю, как с ошибкой управлять.