Я использую rsync
для зеркалирования своей работы (включая Git-репозитории) на разные жесткие диски в качестве меры безопасности от сбоев HD.
Поведение Git по умолчанию - попытаться упаковать файлы с разделителями .pack
в как можно меньшее количество файлов. Это, конечно, приводит к большим .pack
файлам, которые изменяются каждый раз, когда Git перепаковывает репозиторий (так, чтобы базовые данные в дельте всегда были последним коммитом), заставляя rsync
использовать большую пропускную способность, чем хотелось бы (почти всю Размер репозитория будет передан, если вы используете rsync
после того, как Git перепаковал его).
В поисках эффективных способов борьбы с этим, я нашел это сообщение в блоге , которое дает несколько возможных советов:
Если я не пропустил что-то, здесь было три с половиной предложения:
Полностью отключите файлы пакета и gc, что приведет к
накапливать для каждого будущего изменения, и в конечном итоге сделает вещи
помедленнее gc.auto 0, gc.autopacklimit 0.
Установите максимальный размер пакета на меньшее число, чтобы не было файла пакета
становится слишком большим, и последующие слои diffs объединяются в
файлы меньшего размера. pack.packSizeLimit.
Особое мнение по поводу # 2: это не делает то, что вы думаете, оно делает, это
просто нарезает один большой файл пакета на N различных файлов с
те же самые биты в них, так что вы ничего не сохранили.
Если у вас уже есть один гигантский файл пакета, создайте файл .keep следующим
к этому. Новые файлы пакета появятся, но они будут отличаться от
который спас один, и, следовательно, меньше.
Копаясь в git-config docs Я нашел параметр, не упомянутый в сообщении блога выше, и это может быть еще более интересным для моих целей:
gc.bigPackThreshold
Если не ноль, все пакеты больше этого предела
сохраняется при запуске git gc
. Это очень похоже на --keep-base-pack
за исключением того, что все пакеты, которые соответствуют пороговому значению, сохраняются, а не только
Базовый пакет По умолчанию ноль. Обычные единичные суффиксы k, m или g имеют вид
поддерживается.
Обратите внимание, что если количество сохраненных пакетов больше, чем gc.autoPackLimit,
эта переменная конфигурации игнорируется, все пакеты, кроме базового пакета
будет перепакован. После этого количество пачек должно снизиться
gc.autoPackLimit и gc.bigPackThreshold должны соблюдаться снова.
Похоже, что gc.bigPackThreshold
может быть более подходящим для моих целей, чем предложения в посте в блоге (хотя я не уверен, что отключение gc.autoPackLimit
является хорошей идеей, или я должен оставить его со значением по умолчанию 50, или настройте его на большее значение - если его отключение не вызовет нежелательных побочных эффектов, это будет моим предпочтением).
Кто-нибудь в подобном сценарии? Если да, то какие настройки Git вы настроили для получения rsync
производительности?