Jak często powinieneś używać git-gc?

Jak często powinieneś używać git-gc?

Strona podręcznika mówi po prostu:

Zachęca się użytkowników do regularnego uruchamiania tego zadania w każdym repozytorium, aby zachować dobre wykorzystanie miejsca na dysku i dobrą wydajność operacyjną.

Czy są jakieś polecenia, aby uzyskać liczbę obiektów, aby dowiedzieć się, czy nadszedł czas na gc?

Zależy to głównie od tego, ile repozytorium jest używane. Jeden użytkownik loguje się raz dziennie, a operacja rozgałęzienia / scalania / etc raz w tygodniu, prawdopodobnie nie musisz uruchamiać go częściej niż raz w roku.

Z kilkudziesięcioma programistami pracującymi nad kilkadziesiąt projektów, z których każdy sprawdza 2-3 razy dziennie, możesz chcieć uruchamiać go co noc.

Jednak nie zaszkodzi uruchamiać go częściej niż to konieczne.

Chciałbym uruchomić to teraz, a następnie za tydzień zmierzyć wykorzystanie dysku, uruchomić go ponownie i ponownie zmierzyć wykorzystanie dysku. Jeśli spadnie o 5%, uruchom go raz w tygodniu. Jeśli spadnie więcej, uruchom go częściej. Jeśli spadnie mniej, uruchom go rzadziej.

Zauważ, że wadą gromadzenia śmieci w repozytorium jest to, że śmieci są gromadzone. Jak wszyscy wiemy, jako użytkownicy komputerów, pliki, które obecnie uważamy za śmieci, mogą okazać się bardzo cenne trzy dni w przyszłości. Fakt, że git utrzymuje większość swoich śmieci, kilkakrotnie uratował mi bekon - przeglądając wszystkie wiszące zobowiązania, odzyskałem dużo pracy, którą przypadkowo wykonałem.

Więc nie bądź zbyt fajnym dziwakiem w swoich prywatnych klonach. Nie ma takiej potrzeby.

OTOH, wartość odzysku danych jest wątpliwa w przypadku repozytoriów wykorzystywanych głównie jako piloty, np. miejsce, z którego wszyscy deweloperzy pchają i / lub wyciągają. Tam sensowne może być częste rozpoczynanie biegu GC i przepakowywanie.

Najnowsze wersje git uruchamiają gc automatycznie w razie potrzeby, więc nie powinieneś nic robić. Zobacz sekcję Opcje man git-gc (1) : „Niektóre polecenia git uruchamiają git gc - automatycznie po wykonaniu operacji, które mogą spowodować powstanie wielu luźnych obiektów.”

Jeśli używasz Git-Gui , powie Ci, kiedy powinieneś się martwić:

This repository currently has approximately 1500 loose objects.

Następujące polecenie przyniesie podobny numer:

$ git count-objects

Tyle że od samego źródła git-gui sam wykona matematykę, licząc coś w .git/objectsfolderze i prawdopodobnie przybliżając (nie wiem, czy tclpoprawnie to przeczytać!).

W każdym razie wydaje się , że daje ostrzeżenie na podstawie dowolnej liczby około 300 luźnych obiektów.

Rzuć go do pracy crona, która działa co noc (po południu?), Kiedy śpisz.

Używam git gc po tym, jak zrobię dużą kasę i mam dużo nowego obiektu. może zaoszczędzić miejsce. Np. Jeśli kasujesz duży projekt SVN za pomocą git-svn i robisz git gc, zwykle oszczędzasz dużo miejsca

Możesz to zrobić bez żadnych zakłóceń dzięki nowemu ustawieniu (Git 2.0 Q2 2014) gc.autodetach.

Zobacz zatwierdzenie 4c4ac4d i zatwierdzenie 9f673f9 ( Nguyễn Thái Ngọc Duy, aka pclouds ):

gc --autowymaga czasu i może tymczasowo zablokować użytkownika (ale nie mniej denerwujące).
Niech działa w tle na systemach, które go obsługują.
Jedyną rzeczą utraconą podczas pracy w tle są wydruki. Ale gc outputto nie jest naprawdę interesujące.
Możesz utrzymać go na pierwszym planie, zmieniając gc.autodetach.

Od czasu wydania 2.0 pojawił się błąd: git 2.7 (czwarty kwartał 2015) dopilnuje, aby nie stracić komunikatu o błędzie .
Zobacz commit 329e6e8 (19 września 2015) autor: Nguyễn Thái Ngọc Duy ( pclouds) .
^{(Połączone przez Junio ​​C Hamano - gitster- w commit 076c827 , 15 października 2015)}

gc: zapisz dziennik z demonizowanego gc --autoi wydrukuj go następnym razem

Chociaż zatwierdzenie 9f673f9 ( gc: opcja konfiguracji do działania --autow tle - 2014-02-08) pomaga zmniejszyć liczbę skarg związanych z gc --auto„zawieszaniem terminala”, stwarza kolejny zestaw problemów.

Najnowsze w tym zestawie jest, w wyniku demonizacji, stderrzamknięte, a wszystkie ostrzeżenia znikają . To ostrzeżenie na końcu cmd_gc()jest szczególnie ważne, ponieważ informuje użytkownika, jak unikać gc --autopowtarzania się.
Ponieważ stderr jest zamknięty, użytkownik nie wie, oczywiście narzekają na gc --automarnowanie procesora.

Demonizowany gcteraz zapisuje stderrdo $GIT_DIR/gc.log.
Następujące gc --autonie będą działać i gc.logdrukowane, dopóki użytkownik nie usuniegc.log .

Ten cytat pochodzi z; Kontrola wersji za pomocą Git

Git automatycznie uruchamia czyszczenie pamięci :

• Jeśli w repozytorium znajduje się zbyt wiele luźnych obiektów

• Gdy nastąpi wypychanie do zdalnego repozytorium

• Po kilku poleceniach, które mogą wprowadzić wiele luźnych obiektów

• Gdy niektóre polecenia, takie jak git reflog, wygasają, wyraźnie o to poproś

I wreszcie, wyrzucanie elementów bezużytecznych ma miejsce, gdy jawnie zażądasz ich za pomocą polecenia git gc. Ale kiedy to powinno być? Nie ma solidnej odpowiedzi na to pytanie, ale jest kilka dobrych rad i najlepszych praktyk.

Powinieneś rozważyć uruchomienie git gc ręcznie w kilku sytuacjach:

• Jeśli właśnie ukończyłeś gałęzię filtru git. Przypomnij sobie, że gałąź filtra przepisuje wiele zatwierdzeń, wprowadza nowe i pozostawia stare w referencji, które powinny zostać usunięte, gdy będziesz zadowolony z wyników. Wszystkie martwe obiekty (do których nie ma już odniesienia, ponieważ właśnie usunąłeś jeden odnośnik do nich) powinny zostać usunięte poprzez odśmiecanie.

• Po kilku poleceniach, które mogą wprowadzić wiele luźnych obiektów. Może to być na przykład duży wysiłek bazowy.

A z drugiej strony, kiedy należy uważać na zbieranie śmieci?

• Jeśli istnieją osierocone referencje, które możesz chcieć odzyskać

• W kontekście git rerere i nie musisz zapisywać rezolucji na zawsze

• W kontekście tylko tagów i gałęzi wystarczających, aby Git na stałe zachował zatwierdzenie

• W kontekście pobierania FETCH_HEAD (pobieranie bezpośrednio przez URL poprzez git fetch), ponieważ są one natychmiast przedmiotem odśmiecania

Używam, gdy dokonuję dużego zatwierdzenia, przede wszystkim, gdy usuwam więcej plików z repozytorium. Potem zatwierdzenia są szybsze

Nie musisz używać git gczbyt często, ponieważ git gc(Garbage collection) jest uruchamiany automatycznie na kilku często używanych poleceniach:

git pull
git merge
git rebase
git commit

Źródło: najlepsze praktyki git gc i FAQS