Dlaczego git ciągle mi mówi, że to „Automatyczne pakowanie repozytorium w tle dla optymalnej wydajności”?

106

Uwaga : nie sądzę, że jest to duplikat tego pytania , które dotyczy pakietu nie działającego w tle, który zawiesza się git z nieco innym komunikatem o błędzie .

W jednym z moich repozytoriów git, za każdym razem, gdy wywołuję (na przykład) git fetch, git drukuje:

Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.

Wydaje się, że drukuje to za każdym razem, gdy robię to git fetchwielokrotnie, nawet gdy nie ma żadnych zmian i nie ma nic git fetchdo zrobienia. Nie ma to dla mnie większego sensu. Wydaje się, że dzieje się tak również w przypadku innych operacji sieciowych, takich jak git pushi git pull.

Polecenie natychmiast powraca do monitu bez dalszych danych wyjściowych i nie mogę znaleźć żadnego procesu git działającego na moim komputerze. Wydaje się, że dzieje się to tylko z tym repozytorium i tylko na tym komputerze. git config -l | grep gcnic nie zwraca.

Co mogę zrobić, aby zdiagnozować lub rozwiązać ten problem?

$ git --version 
git version 2.0.1

Używam OS X 10.9.

git background-process packing

— Andrew Ferrier
źródło

Wygląda na to, że problem dotyczy tego samego pytania, ale dzieje się to na tyle szybko, że nie wydaje się zawieszać.

— Holloway,

Prawdopodobnie

— Holloway,

Trengot, nie sądzę. Komunikat o błędzie jest nieco inny - wspomina o „tle”.

— Andrew Ferrier,

Trengot, przepraszam, miałeś rację, to było powiązane (drugi link). Dzięki za wskazówkę, zobacz moją odpowiedź poniżej, aby uzyskać szczegółowe informacje.

— Andrew Ferrier,

175

Znalazłem rozwiązanie z drugiego komentarza, który podałeś, Trengot, dzięki. Okazuje się, że miałem zwisające bąble, które były w środku, .git/objects/17a tym samym uruchamiały pakowanie:

$ git fsck
dangling blob d9ff0aeac4aa8b4e0907daed675ebf60278bc977
dangling blob dbff2d073741f9775c815d4a3c623736af224dad
dangling blob e1ffbab1c5b985cd1cd3bc0281075ea2ed80744a
dangling blob fdff59878ccb3a75689f4acca615cfb635288774

To je oczyściło:

$ git gc --prune=now

Pamiętaj, zgodnie z komentarzem Henrika poniżej, może to być trochę niebezpieczne. Dbać!

— Andrew Ferrier
źródło

Dzięki! To wydawało się działać dla mnie. Pamiętaj, że --prune=nowjest to trochę niebezpieczne. Domyślnie --prunezachowuje 2 tygodnie wiszących obiektów blob, co oznacza, że jeśli przypadkowo wykonałeś niepoprawną rebase 5 minut temu lub wczoraj usunąłeś gałąź, możesz odzyskać. Po uruchomieniu tego polecenia tracisz wszystkie wiszące blogi aż do teraz - nie 2 tygodnie temu. Ponadto wydaje się, że nigdy nie powinieneś go uruchamiać podczas wykonywania innych poleceń Git w innym terminalu, w przeciwnym razie repozytorium może zostać uszkodzone.

— Henrik N,

Uratowałeś mi dzień

— Owen Chen,