Cały zespół otrzymuje komunikat "zbyt wiele nieosiągalnych obiektów"

Question

Nie tak dawno temu przełączyliśmy się z SVN na Git.

Kilka dni temu zdałem sobie sprawę, że cały nasz zespół dostaje te wiadomości, kiedy pchania:

$ 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 

myślałem, że to pochodzi z mojego komputera przez jakiś czas, dopóki nie uświadomić sobie, że każdy ma takie same problemy.

Nie trzeba dodawać, że w moim folderze .git nie ma pliku gc.log, a użycie "git gc" lub "git prune" nie ma żadnego efektu.

Moje pytanie brzmi: czy to możliwe, że repozytorium hostowane na serwerze nie jest w jakiś sposób czyste? Jeśli tak, to jak to wyczyścić?

Wszystkie dotychczasowe rozwiązania dotyczą lokalnych kopii repozytoriów.

Ponadto używamy Gitlab do hostowania naszych repo.

EDYCJA: Warto powiedzieć, że od kiedy napisałem to pytanie, wypróbowałem również "Housecleaning" repozytorium za pomocą Gitlab, ale bez rezultatu do tej pory.

Dzięki

Answer 1

tym następuje issue 14357 (GitLab 8.6- lub mniej)

Instrukcja fix było:

• SSH do worker1
• cd do gitlab-org/gitlab -catalog
• prowadził rm gc.log, zawierało tylko linię "ostrzeżenie: jest zbyt wiele nieosiągalnych luźnych obiektów ; uruchomić 'git prune', aby je usunąć.”
• prowadził git prune i modlił się, że nie złamał rzeczy (które na szczęście nie)

Ale wygląda na to, począwszy GitLab 8,7, auto gc is disabled.
jest to również zrobić w kontekście (still opened) issue 13524:

Zazwyczaj po rebase zmieniają lub inne działanie, które wymaga push force możemy mieć zwisały zobowiązuje

TAKI. komendy "dereferencyjne" gubią się z powodu git gc, które mogą być wykonywane wewnętrznie lub przy użyciu funkcji GitLab Housekeeping.

Jeśli zdarzy się, że do określonego zatwierdzenia została dołączona dyskusja - nie jest ona dostępna po usunięciu wywołania z pamięci.

Przyjęcia są rejestrowane w zdarzeniach push i są dostępne poprzez uwagi systemowe dodane do żądania scalenia, a obecnie powoduje to błąd 500 w GitLab.