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

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

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

Ответ 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).

Ответ 2

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

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

git gc --prune=now

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

Ответ 3

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

cd your_project_dir
git config gc.auto 0

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

git config --global gc.auto 0

Ответ 4

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

Ответ 5

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

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

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

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

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

И Git 2.22 (Q2 2019) дополнительно оптимизирует git gc.