Come saltare popup "Loose oggetto" durante l'esecuzione di 'git gui'

Question

Quando eseguo 'git gui' ho un popup che dice

 
This repository currently has approximately 1500 loose objects. 

Suggerisce quindi comprimere il database. L'ho già fatto prima e riduce gli oggetti liberi a circa 250, ma ciò non sopprime il popup. La compressione di nuovo non cambia il numero di oggetti liberi.

Il flusso di lavoro corrente richiede un uso significativo di "rebase" mentre stiamo passando da Perforce e Perforce è ancora lo SCM canonico. Una volta che Git è l'SCM canonico, faremo fusioni regolari e il problema degli oggetti mobili dovrebbe essere fortemente mitigato.

Nel frattempo, mi piacerebbe davvero far scomparire questo popup "utile".

Answer 1

Dal momento che nessuno aveva ancora una risposta, ho esaminato il codice per vedere come rimuovere il codice che mostra quel dialogo. Ho trovato la procedura hint_gc che lo fa e il luogo in cui è chiamato. Allo stesso tempo ho notato che alla fine del 2011 è stato aggiunto a configuration option for disabling the dialog. Questo cambiamento (parte di git-gui 0.16.0) è stato unito alla linea principale di Git su 2011-12-14.

Quindi, se si utilizza Git v1.7.9 o più recente, è possibile disattivare la finestra di avviso con il seguente comando:

git config --global gui.gcwarning false 

Se si utilizza una versione precedente, quindi è possibile modificare e rimuovere /lib/git-core/git-gui la riga after 1000 hint_gc o modificare /usr/share/git-gui/lib/database.tcl e rimuovere il corpo della procedura hint_gc. (Questi percorsi di file sono su Cygwin - su altri ambienti i file potrebbero essere in posizioni diverse. Per Windows è c:\Program Files\Git\mingw64\libexec\git-core\git-gui.tcl)

Answer 2

Quando "Loose oggetto" pop-up So che è il momento di eseguire garbage collector di git:

git gc 

Dopo che il popup va via.

Aggiornamento: (a causa di suggerimento di T.E.D.)

ho estratto la routine sotto da git/share/git-gui/lib/database.tcl
È possibile modificarlo per soddisfare le vostre esigenze.

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 
     } 
    } 
} 

Answer 3

Hmmmm .... non vedo un argomento della riga di comando per che nel docs.

Suppongo che si possa sempre estrarre la fonte, estrarre il codice per la finestra di dialogo e ricostruire.

Answer 4

Aggiornamento: git prune sarebbe "risolvere" il problema, nel senso che rimuoverà quegli oggetti sciolti
(git gc chiamate git prune, ma solo per gli oggetti sciolti più vecchi di due settimane, per impostazione predefinita).
Tuttavia, come la OP Michael Donohue menzioni nei commenti:

mi piace l'aspetto della sicurezza di tenere gli oggetti liberi in giro per due settimane, dovrei desiderare di tornare indietro e guardare alcune vecchie revisioni, così ho don Mi piace molto questa soluzione.
Non ho alcun problema con le dimensioni o le prestazioni di git, è solo 'git gui' che insiste nel chiedermi di comprimere il database, anche se la compressione del database non avrebbe alcun effetto.

---

risposta originale:

Il problema della "git gc" non rimuovendo tutti oggetti liberi stato segnalato prima (fine del 2008, ""git gc" doesn't seem to remove loose objects any more"

git gc rimuove solo sciolto oggetti più vecchi di due settimane, se davvero vuoi rimuoverli adesso, esegui git prune
Ma fai certo nessun altro processo git può essere attivo quando lo si esegue, o potrebbe eventualmente fare un passo su su qualcosa.

"git gc" sarà decomprimere oggetti che sono diventati irraggiungibili ed erano attualmente in pacchetti.
Come risultato, la quantità di spazio su disco utilizzata da un repository git può effettivamente andare su in modo drammatico dopo un'operazione "git gc", che potrebbe essere sorprendente per qualcuno che sta correndo vicino al suo filesystem, elimina un numero di rami da un repository di tracciamento, e quindi fa un "git gc" può ottenere una sorpresa molto spiacevole.

[ Esempio: ] I vecchi rami sono riservati tramite un tag come next-20081204.
Se si aggiorna la copia locale del repository linux-next ogni giorno, si accumulerà un gran numero di questi vecchi tag di ramo.
Se si elimina una serie intera di esse ed è in esecuzione git-gc, l'operazione richiederà un po 'di tempo e il numero di blocchi e di inode utilizzati aumenterà in modo significativo.

Essi scompaiono dopo un "git prune", ma quando eseguo questa operazione di manutenzione, ho spesso desiderato l'opzione --yes-I-know-what-I-am-doing-and-it's-unsafe-but-just-drop-the-unreachable-objects-cause-this-is-just-a-tracking-repository per "git gc".

Quindi, nel tuo caso, sarebbe un "git prune" essere utile?

(possibilmente con l'utilizzo di "now" nella variabile di configurazione gc.pruneexpire, necessario per il comportamento sopra riportato).

---

Hai anche (dallo stesso filo):

repack -a -d -l 

Avviso la minuscola 'a'.

git-gc chiama repack con maiuscolo 'A', che è ciò che causa lo spacchettamento degli oggetti non raggiungibili. Little 'a', è per le persone che sanno quello che stanno facendo e vogliono che git tocchi solo oggetti irraggiungibili.