Целая команда получает слишком много сообщений недоступных незакрепленных объектов

Не так давно мы перешли от 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 [email protected]:root/xxx.git
   15c3bbb..69e6d8b  xxxx -> xxx

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

Излишне говорить, что в моей папке .git нет gc.log, и использование 'git gc' или 'git prune' не имеет никакого эффекта.

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

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

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

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

Спасибо

Ответ 1

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

Исправление было:

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

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

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

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

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

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

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

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

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

MR 4101: Рефакторинг: преобразование существующего массива diff refs в модель DiffRefs