Что означает «Автоматическая упаковка хранилища для оптимальной производительности»?

Question

У меня проблема с моим git-репо.В течение последних нескольких дней, когда я делаю отправку на сервер, я получаю это сообщение: «Автоматическая упаковка хранилища для оптимальной производительности», и, похоже, он не исчезает и возвращает оболочку.

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

Answer 1

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

Во время большинства операций, которые могут потенциально увеличить количество незакрепленных (распакованных) объектов в хранилище (включая нажатия), Git вызывает git gc --auto.Если свободных объектов достаточно (по умолчанию не менее 6700), он вызовет git repack -d -l для их упаковки.Если существует слишком много отдельных пакетов, он также упакует их в один.

Пакет представляет собой отдельный файл с дельта-сжатием, содержащий большое количество объектов.Более эффективно хранить объекты в пакетах, но для упаковки (сжатия) объектов требуется время, поэтому Git сначала создает незакрепленные объекты, а затем упаковывает их порциями, а затем автоматически вызывает git gc --auto.

Если вы позволите Git закончить переупаковку, это не повторится некоторое время. Это может действительно занять некоторое время, особенно если у вас много больших двоичных объектов, но если он запускается, то это знакчто это, вероятно, значительно сократит объем дискового пространства, занимаемого репо.Если вы действительно не хотите, чтобы это произошло, вы можете изменить параметр конфигурации gc.auto.Если вы увеличите его до чего-то намного большего, чем 6700, это будет происходить реже, но это займет больше времени.Если вы уменьшите его, вам все равно придется выполнить текущий перепак, но впоследствии это будет происходить чаще и быстрее заканчиваться.Если вы установите значение 0, автоматическая перепаковка будет отключена.

См. man git-gc (под --auto) и man git-config (под gc.auto) для получения дополнительной информации.

Answer 2

Хотя Джефрони и прав, что иногда для автоматической упаковки просто требуется время для завершения, если сообщение автоматической упаковки сохраняется в течение нескольких дней, как описано в OP, есть большая вероятность, что при очистке git отсутствуют висячие объекты, как описано в этот вопрос .

Чтобы увидеть, вызывают ли висящие объекты текущие сообщения об автоматической упаковке, попробуйте запустить git fsck.Если вы получаете длинный список висячих коммитов, вы можете очистить их с помощью

git gc --prune=now

Мне обычно приходится запускать это в своем репо каждые 2-3 месяца, когда сообщение об автоматической упаковкене уходит после одного рывка.

Answer 3

Чтобы отключить для одного проекта:

cd your_project_dir
git config gc.auto 0

Чтобы отключить глобально:

git config --global gc.auto 0

Answer 4

Git запускает git-repack, который упаковывает множество объектов (= файлы, коммиты и деревья) в один файл пакета. Git делает это иногда, когда эвристик говорит, что может быть сэкономлено место (файл пакета содержит сжатые данные об объектах, в то время как каждый файл в каталоге objects / содержит сжатый полный файл содержимого)

Answer 5

Надеюсь, что шаг git gc --auto теперь (git 2.0.1, 25 июня 2014 г.) более эффективен.
См. коммит 62aad18 от Нгуен Тхай Нгёк Дуй (pclouds)

gc --auto: не блокировать ссылки в фоновом режиме

9f673f9 (gc: опция конфигурации для запуска --auto в фоновом режиме - 2014-02-08, Git 2.0.0) помещает "gc --auto" в фоновом режиме, чтобы сократить время ожидания пользователя.
Часть сбора мусора - сборщики мусора и обрезки. Это требует блокировки некоторых ссылок и может прервать другие процессы, пытаясь заблокировать ту же ссылку.

Если в середине скрипта сработает gc --auto, то удержание блокировок в фоновом режиме может привести к сбою скрипта, чего никогда не было раньше 9f673f9 .

Продолжайте работать pack-refs и "reflog --prune" на переднем плане, чтобы остановить параллельные обновления ссылок. Остальные фоновые операции (переупаковка, удаление и повторное создание) не должны влиять на запущенные процессы git.

И Git 2.22 (Q2 2019) Дальнейшая оптимизация git gc.