Jak pominąć wyskakujące okienko „Loose Object” podczas uruchamiania „git gui”

Kiedy uruchamiam „git gui”, pojawia się wyskakujące okienko z napisem

To repozytorium zawiera obecnie około 1500 luźnych obiektów.

Następnie sugeruje kompresję bazy danych. Robiłem to już wcześniej i zmniejsza to liczbę luźnych obiektów do około 250, ale to nie blokuje wyskakującego okienka. Ponowne kompresowanie nie zmienia liczby luźnych obiektów.

Nasz obecny przepływ pracy wymaga znacznego wykorzystania „rebase”, ponieważ przechodzimy z Perforce, a Perforce jest nadal kanonicznym SCM. Gdy Git stanie się kanonicznym SCM, będziemy wykonywać regularne połączenia, a problem luźnych obiektów powinien zostać znacznie złagodzony.

W międzyczasie naprawdę chciałbym, aby to „pomocne” wyskakujące okienko zniknęło.

Ponieważ nikt nie miał jeszcze odpowiedzi, zajrzałem do kodu, aby zobaczyć, jak usunąć kod, który wyświetla to okno dialogowe. Znalazłem hint_gcprocedurę, która to robi i miejsce, w którym się nazywa. Jednocześnie zauważyłem, że pod koniec 2011 roku dodano opcję konfiguracji wyłączania okna dialogowego . Zmiana ta (część git-gui 0.16.0) został włączony do Mainline git w dniu 2011-12-14 .

Jeśli więc używasz Git w wersji 1.7.9 lub nowszej, możesz wyłączyć okno ostrzegawcze za pomocą następującego polecenia:

git config --global gui.gcwarning false

Jeśli używasz starszej wersji, możesz edytować /lib/git-core/git-guii usunąć after 1000 hint_gclinię lub edytować /usr/share/git-gui/lib/database.tcli usunąć treść hint_gcprocedury. (Te ścieżki plików znajdują się w Cygwin - w innych środowiskach pliki mogą znajdować się w innych lokalizacjach. W przypadku systemu Windows tak jest c:\Program Files\Git\mingw64\libexec\git-core\git-gui.tcl)

Aktualizacja: git prune„rozwiązałoby” problem, ponieważ usunie te luźne przedmioty
( git gcpołączenia git prune, ale domyślnie tylko w przypadku luźnych przedmiotów starszych niż dwa tygodnie).
Jednak, jak wspomina OP Michael Donohue w komentarzach:

Podoba mi się aspekt bezpieczeństwa polegający na przechowywaniu luźnych przedmiotów przez dwa tygodnie, gdybym chciał wrócić i spojrzeć na niektóre stare wersje, więc nie podoba mi się to rozwiązanie.
Nie mam żadnych problemów z rozmiarem ani wydajnością gita, to po prostu „git gui” nalega na proszenie mnie o skompresowanie bazy danych, nawet jeśli kompresja bazy danych nie przyniesie żadnego efektu.

Oryginalna odpowiedź:

Problem z " git gc" nieusuwaniem wszystkich luźnych obiektów został już zgłoszony (koniec 2008 r., " " git gc"Nie wydaje się już usuwać luźnych obiektów "

git gcusuwa tylko luźne przedmioty starsze niż dwa tygodnie, jeśli naprawdę chcesz je teraz usunąć, uruchom git prune.
Ale upewnij się, że żaden inny proces git nie może być aktywny, gdy go uruchomisz, lub może on nadepnąć na coś.

" git gc" rozpakuje obiekty, które stały się nieosiągalne i były obecnie w paczkach.
W rezultacie, ilość miejsca na dysku używane przez repozytorium git może faktycznie się dramatycznie po „ git gc” operacji, co może być zaskakujące dla kogoś, kto jest uruchomiony niemal w pełni na swoim systemie plików, usuwa szereg gałęzi z repozytorium śledzenia , a następnie „ git gc” może spowodować bardzo nieprzyjemną niespodziankę.

[Przykład: ]Stare gałęzie są rezerwowane za pomocą tagu, takiego jak next-20081204.
Jeśli codziennie aktualizujesz lokalną kopię linux-nextrepozytorium, zgromadzisz dużą liczbę starych znaczników gałęzi.
Jeśli następnie usuniesz całą ich serię i uruchomisz git-gc, operacja zajmie trochę czasu, a liczba używanych bloków i i-węzłów znacznie wzrośnie.

Znikną po " git prune", ale kiedy wykonuję tę operację porządkową, często marzyłem o --yes-I-know-what-I-am-doing-and-it's-unsafe-but-just-drop-the-unreachable-objects-cause-this-is-just-a-tracking-repositoryopcji "git gc".

Więc w twoim przypadku, czy „ git prune” byłoby pomocne?

(prawdopodobnie z użyciem „now” w gc.pruneexpirezmiennej konfiguracyjnej, potrzebnej do wystąpienia powyższego zachowania).

Masz również (z tego samego wątku):

repack -a -d -l

Zwróć uwagę na małą literę „a”.

git-gcwywołuje repack z wielkimi literami „A”, co powoduje rozpakowanie nieosiągalnych obiektów. Małe „a” jest dla ludzi, którzy wiedzą, co robią i chcą, aby git po prostu upuścił nieosiągalne obiekty.

Gdy wyskakuje okienko „Loose Object”, wiem, że czas uruchomić garbage collector git:

git gc

Następnie wyskakujące okienko zniknie.

Aktualizacja: (zgodnie z sugestią TED)

wyodrębniłem poniższą procedurę z git/share/git-gui/lib/database.tcl
Możesz ją zmodyfikować, aby spełniała Twoje potrzeby.

proc hint_gc {} {
    set object_limit 8
    if {[is_Windows]} {
        set object_limit 1
    }

    set objects_current [llength [glob \
        -directory [gitdir objects 42] \
        -nocomplain \
        -tails \
        -- \
        *]]

    if {$objects_current >= $object_limit} {
        set objects_current [expr {$objects_current * 256}]
        set object_limit    [expr {$object_limit    * 256}]
        if {[ask_popup \
            [mc "This repository currently has approximately %i loose objects.

To maintain optimal performance it is strongly recommended that you compress the database when more than %i loose objects exist.

Compress the database now?" $objects_current $object_limit]] eq yes} {
            do_gc
        }
    }
}

Hmmmm .... Nie widzę argumentu wiersza poleceń na to w dokumentacji .

Przypuszczam, że zawsze można było usunąć jego źródło, wyjąć kod okna dialogowego i przebudować.