Вся команда получает сообщения "слишком много недостижимых свободных объектов".

Не так давно, мы сделали переход с SVN на Git.

Несколько дней назад я понял, что вся наша команда получает эти сообщения, когда они нажимают: 
$ git push
Counting objects: 32, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (19/19), done.
Writing objects: 100% (32/32), 2.94 KiB | 0 bytes/s, done.
Total 32 (delta 14), reused 0 (delta 0)
error: The last gc run reported the following. Please correct the root cause
and remove gc.log.
Automatic cleanup will not be performed until the file is removed.

warning: There are too many unreachable loose objects; run 'git prune' to remove them.

To git@git.ad.xxx.se:root/xxx.git
   15c3bbb..69e6d8b  xxxx -> xxx
Я некоторое время думал, что это исходит от моего компьютера, пока не понял, что у всех одни и те же проблемы.

Излишне говорить, что нет никакого gc.войдите в мой .папку Git, и используя 'ГИТ ГК' или 'ГИТ чернослив' не имеет никакого эффекта.

Итак, мой вопрос: Может ли быть так, что репозиторий, размещенный на сервере, каким-то образом не чисто? Если да, то как мне на самом деле очистить его?

Все решения, которые я нашел до сих пор, относятся к локальным копиям репозиториев.

Кроме того, мы используем Gitlab для размещения наших РЕПО.

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

Спасибо

1 16
garbage-collection gitlab

1 ответ:

За этим следует выпуск 14357 (GitLab 8.6-или меньше)

Ручное исправление было:

  • SSH в worker1
  • cd в каталог GitLab-org/gitlab-ce
  • ran rm gc.log, это просто содержало строку "предупреждение: слишком много недостижимых свободных объектов; запустите 'git prune', чтобы удалить их."
  • бежал git prune и молился, чтобы он ничего не сломал (чего, к счастью, не произошло)

Но похоже, что, начиная GitLab 8.7, auto gc является отключен .
Это также делается в контексте (все еще открытого) вопроса 13524:

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

Такие "разыменованные" коммиты теряются из-за git gc, которые могут выполняться внутри системы или с помощью функций GitLab Householding.

Если случилось так, что обсуждение было прикреплено к конкретному коммиту - оно недоступно после разыменования фиксация была собрана мусором.

Коммиты записываются в push-события и доступны через системные заметки, добавленные в запрос слияния, и в настоящее время это приводит к ошибке 500 в GitLab.

Обновление: этот вопрос был закрыт месяц спустя (июль 2016) с:

  • MR 5062: Не собирайте мусор коммитов, которые имеют связанные записи БД, такие как комментарии

Гарантирует, что фиксация сохраняется при выполнении сборки мусора Git.
Git GC удалит коммиты из репозитория, которые больше не находятся ни в каких ветвях или тегах, но мы хотим сохранить некоторые из этих коммитов, например, если у них есть комментарии или сборки CI.

  • мистер 4101: рефакторинг: преобразовать существующий массив на основе сравнения ссылки на модели DiffRefs
15