Подтвердить что ты не робот

Почему git запускает "git gc -auto" при каждом слиянии?

Сегодня git начал играть смешно (ну, смешно, чем обычно), настаивая на запуске git gc после каждого отдельного слияния, даже если они вернулись назад.

C:\Projects\my-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). Мои опасения необоснованны? Если мой репозиторий в порядке, как мне сделать остановку автоматической упаковки?!

4b9b3361

Ответ 1

ИЗМЕНИТЬ

Я думаю, что я заметил проблему.

Вероятно, вы используете Cygwin/ git или MsysGit для Windows. Я заметил, что из-за

FIND: Parameter format not correct

сообщение об ошибке. Проблема в том, что где-то ваши скрипты hook (или git internal?!) вызывают find, который не находит утилиту поиска UNIX (GNU), а скорее находит Windows (MSDOS... sic) FIND.EXE.

Вы должны иметь возможность исправить свой системный путь. Если это не вариант, явно укажите переменную среды PATH внутри вашего script (или перед вызовом)


Старый ответ для информации:

<суб >

git gc --auto не всегда приводит к каким-либо действиям; вы уверены, что это занимает время каждый раз, или вы только заметили, что его называют?

Если он вызывается каждый раз, вы можете

  • проверить права на репозиторий (убедитесь, что он полностью доступен для записи!)
  • git fsck
  • git repack
  • git bundle --create mybundle.git --all и git clone mybundle.git, чтобы увидеть, как-то вы можете "встряхнуть" преступника
  • посмотреть, можно ли перейти на более позднюю версию
  • если все остальное не удается, разделите или отлаживайте git -gc двоичный

При желании, когда вы сотрясаете виновника, вы, возможно, сможете проанализировать, что отличает ваш "очищенный" репо и текущий.

От git -gc man-страница:

С помощью этой опции git gc проверяет, требуется ли ведение домашнего хозяйства; если нет, то он выходит без выполнения    любая работа. Некоторые команды git запускают git gc -auto после выполнения операций, которые могут создать много    объекты.

Уборка требуется, если в репозитории слишком много свободных объектов или слишком много пакетов. Если    количество незакрепленных объектов превышает значение переменной конфигурации gc.auto, тогда все свободные объекты    объединены в один пакет, используя git repack -d -l. Установка значения gc.auto на 0 отключает    автоматическая упаковка рыхлых предметов.

Если количество пакетов превышает значение gc.autopacklimit, тогда существующие пакеты (кроме отмеченных    с .keep файлом) объединяются в один пакет, используя опцию -A для git repack. настройка    gc.autopacklimit до 0 отключает автоматическую консолидацию пакетов.

суб >

Ответ 2

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

Когда один из моих репозиториев запускает "Автоматическую упаковку репозитория для оптимальной производительности" после каждого слияния,

git gc --prune=now

исправляет это. (Находясь на Mac, у меня нет проблемы с FIND: Parameter format not correct.) Сейчас я использую git 2.4.1, но это сработало для меня для нескольких версий 2. *.

Этот ответ в Как удалить неопубликованные капли из моего git repo предполагает, что может потребоваться очистить один рефлог с помощью

git reflog expire --expire-unreachable=now --all

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

Ответ 3

Какую версию git вы используете? Несмотря на это, я считаю автоматический gc чрезвычайно экстремальным.

git config --global gc.auto 0

Ответ 4

В вашем репозитории должно быть много объектов, хэши которых начинаются с 17. Таким образом, это вызывает git gc -auto. По умолчанию используется как минимум 28 объектов с префиксом 17.