Почему git запускает "git gc --auto" при каждом слиянии?
сегодня git начал действовать смешно (ну, смешнее, чем обычно), настаивая на запуске git gc
после каждого слияния, даже если они спиной к спине.
C:Projectsmy-current-project>git pull
remote: Counting objects: 31, done.
remote: Compressing objects: 100% (16/16), done.
remote: Total 16 (delta 11), reused 0 (delta 0)
Unpacking objects: 100% (16/16), done.
From git.company.com:git/
e992ce8..6376211 mybranch/next -> origin/mybranch/next
Merge made by recursive.
Auto packing the repository for optimum performance. You may also run "git gc" manually. See "git help gc" for more information.
FIND: Parameter format not correct
Counting objects: 252732, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (59791/59791), done.
Writing objects: 100% (252732/252732), done.
Total 252732 (delta 190251), reused 252678 (delta 190222)
Removing duplicate objects: 100% (256/256), done.
.../stylesheets/style.css | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Это невероятно разрушительно, и я боюсь, что это означает, что мой репозиторий поврежден каким-то образом (это первый раз, когда я когда-либо видел его автоматически gc
). Мои страхи необоснованны? Если мой репозиторий в порядке, как сделать остановку автоматической упаковки?!
3 ответов
редактировать
кажется, я заметил проблему.
вероятно, вы используете Cygwin / git или MsysGit в Windows. Я заметил это из-за
FIND: Parameter format not correct
сообщение об ошибке. Проблема в том, что где-то ваши скрипты крючка (или git внутренне?!) вызывает find, который не находит утилиту Unix (GNU) find, а скорее находит Windows (MSDOS... sic) найти.ИСПОЛНЯЕМЫЙ.
вы должны иметь возможность исправить свой системный путь. Если это не опция, явно укажите переменную среды PATH внутри вашего скрипта (или перед их вызовом)
старый ответ на информацию:
git gc --auto
не всегда приводит к каким-либо действиям; вы уверены, что это занимает время каждый раз, или вы просто заметили, что это называется?
если он вызывается каждый раз, вы могли бы
- проверить разрешения репозитория (убедитесь, что он полностью записывается для вас!)
- git fsck
- git repack
-
git bundle --create mybundle.git --all
иgit clone mybundle.git
чтобы увидеть, как-то вы можете "встряхнуть" виновника - посмотреть, можно ли обновить до более поздней версии
- если все остальное не удается, strace или debug двоичный файл git-gc
необязательно, когда вы встряхнули виновника, вы, возможно, сможете проанализировать, что отличается между вашим "очищенным" РЕПО и текущим.
от человек-страница git-gc:
С этой опцией git gc проверяет, требуется ли какая-либо уборка; если нет, он выходит без выполнения любая работа. Некоторые команды git запускают git gc --auto после выполнения операций, которые могут создать много свободных объекты.
уборка требуется, если в репозитории слишком много свободных объектов или слишком много пакетов. Если количество сыпучих объектов превышает значение gc.автоматическая конфигурация переменная, затем все свободные объекты объединяются в один пакет с помощью Git repack-d-l. Установка значения gc.авто на 0 отключает автоматическая упаковка сыпучих предметов.
если количество пакетов превышает значение gc.autopacklimit, затем существующие пакеты (кроме отмеченных с .keep file) объединяются в один пакет с помощью опции-a git repack. Установочный сборщик мусора.autopacklimit to 0 отключает автоматическую консолидацию пакеты.
Я добавляю этот ответ, хотя он не отвечает на конкретную проблему оригинального плаката, потому что каждый раз, когда один из моих репозиториев начинает автоматическую упаковку после каждого слияния, я забыл исправление, найдите его снова и сначала найдите этот вопрос.
когда один из моих репозиториев начинает "автоматическую упаковку репозитория для оптимальной производительности" после каждого слияния,
git gc --prune=now
фиксирует его. (Будучи на Mac, у меня нет
какую версию git вы используете? Несмотря на это, я нахожу automatic gc
ing чрезвычайно разрушительный.
git config --global gc.auto 0