Quanto spesso dovresti usare git-gc?

Quanto spesso dovresti usare git-gc?

La pagina del manuale dice semplicemente:

Gli utenti sono incoraggiati a eseguire questa attività su base regolare all'interno di ciascun repository per mantenere un buon utilizzo dello spazio su disco e buone prestazioni operative.

Ci sono alcuni comandi per ottenere alcuni conteggi di oggetti per scoprire se è il momento di gc?

Dipende principalmente da quanto viene utilizzato il repository. Con un utente che effettua il check-in una volta al giorno e un'operazione di branch / merge / etc una volta alla settimana, probabilmente non è necessario eseguirla più di una volta all'anno.

Con diverse dozzine di sviluppatori che lavorano su diverse dozzine di progetti, ognuna delle quali esegue il check-in 2-3 volte al giorno, potresti volerla eseguire di notte.

Tuttavia, non sarà male eseguirlo più frequentemente del necessario.

Quello che farei è eseguirlo ora, quindi tra una settimana prendere una misurazione dell'utilizzo del disco, eseguirlo di nuovo e misurare di nuovo l'utilizzo del disco. Se diminuisce del 5%, eseguilo una volta alla settimana. Se scende di più, eseguilo più frequentemente. Se diminuisce di meno, eseguilo meno frequentemente.

Nota che il lato negativo della raccolta dei rifiuti nel tuo repository è che, beh, la spazzatura viene raccolta. Come tutti sappiamo come utenti di computer, i file che consideriamo spazzatura in questo momento potrebbero rivelarsi molto preziosi tre giorni in futuro. Il fatto che Git mantenga la maggior parte dei suoi detriti in giro mi ha salvato diverse volte la pancetta - sfogliando tutti i commit penzolanti, ho recuperato molto lavoro che avevo accidentalmente inscatolato.

Quindi non essere troppo maniaco dei cloni privati. C'è poco bisogno per questo.

OTOH, il valore della recuperabilità dei dati è discutibile per i repository usati principalmente come telecomandi, ad es. il posto in cui tutti gli sviluppatori spingono e / o tirano da. Lì, potrebbe essere sensato dare il via a una corsa GC e un reimballaggio frequente.

Le versioni recenti di git eseguono gc automaticamente quando richiesto, quindi non dovresti fare nulla. Vedi la sezione Opzioni di man git-gc (1) : "Alcuni comandi git eseguono git gc --auto dopo aver eseguito operazioni che potrebbero creare molti oggetti sciolti."

Se stai usando Git-Gui , ti dice quando dovresti preoccuparti:

This repository currently has approximately 1500 loose objects.

Il seguente comando porterà un numero simile:

$ git count-objects

Tranne che dalla sua fonte , git-gui farà i calcoli da sola, contando effettivamente qualcosa nella .git/objectscartella e probabilmente porta un'approssimazione (non so tclleggerlo correttamente!).

In ogni caso, sembra dare l'avvertimento basato su un numero arbitrario di circa 300 oggetti sciolti.

Rilascialo in un cron job che viene eseguito ogni notte (pomeriggio?) Quando dormi.

Uso git gc dopo aver fatto un grosso checkout e ho molti nuovi oggetti. può risparmiare spazio. Ad esempio, se fai il checkout di un grande progetto SVN usando git-svn e fai un git gc, in genere risparmi molto spazio

Puoi farlo senza alcuna interruzione, con la nuova impostazione (Git 2.0 Q2 2014) gc.autodetach.

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

gc --autorichiede tempo e può bloccare l'utente temporaneamente (ma non meno fastidiosamente).
Fallo funzionare in background sui sistemi che lo supportano.
L'unica cosa persa con l'esecuzione in background sono le stampe. Ma gc outputnon è davvero interessante.
Puoi tenerlo in primo piano cambiando gc.autodetach.

Da quella versione 2.0, però, c'era un bug: git 2.7 (Q4 2015) farà in modo di non perdere il messaggio di errore .
Vedi commit 329e6e8 (19 set 2015) di Nguyễn Thái Ngọc Duy ( pclouds) .
^{(Unita da Junio ​​C Hamano - gitster- in commit 076c827 , 15 ottobre 2015)}

gc: salva il log da daemonized gc --autoe stampalo la prossima volta

Mentre commit 9f673f9 ( gc: opzione di configurazione per l'esecuzione --autoin background - 08-02-2014) aiuta a ridurre alcuni reclami relativi al "controllo gc --autodel terminale", crea un altro insieme di problemi.

L'ultima di questo set è, come risultato della demonizzazione, stderrè chiusa e tutti gli avvisi sono persi. Questo avviso alla fine di cmd_gc()è particolarmente importante perché indica all'utente come evitare " gc --auto" di essere eseguito ripetutamente.
Poiché stderr è chiuso, l'utente non lo sa, naturalmente si lamentano di gc --auto"spreco di CPU.

Daemonized gcora salva stderra $GIT_DIR/gc.log.
Il seguito gc --autonon verrà eseguito e gc.logstampato fino alla rimozione dell'utentegc.log .

Questa citazione è presa da; Controllo versione con Git

Git esegue automaticamente la garbage collection :

• Se ci sono troppi oggetti sciolti nel repository

• Quando si verifica un push in un repository remoto

• Dopo alcuni comandi che potrebbero introdurre molti oggetti sciolti

• Quando alcuni comandi come git reflog scadono, lo richiedono esplicitamente

E infine, la garbage collection si verifica quando lo richiedi esplicitamente usando il comando git gc. Ma quando dovrebbe essere? Non c'è una risposta solida a questa domanda, ma ci sono alcuni buoni consigli e buone pratiche.

Dovresti considerare di eseguire git gc manualmente in alcune situazioni:

• Se hai appena completato un ramo del filtro git. Ricorda che il ramo del filtro riscrive molti commit, ne introduce di nuovi e lascia quelli vecchi su un riferimento che dovrebbe essere rimosso quando sei soddisfatto dei risultati. Tutti quegli oggetti morti (a cui non si fa più riferimento da quando hai appena rimosso un riferimento che li punta) dovrebbero essere rimossi tramite Garbage Collection.

• Dopo alcuni comandi che potrebbero introdurre molti oggetti sciolti. Questo potrebbe essere un grande sforzo di ribasso, per esempio.

E il rovescio della medaglia, quando dovresti stare attento alla raccolta dei rifiuti?

• Se ci sono riferimenti orfani che potresti voler recuperare

• Nel contesto di git rerere e non è necessario salvare le risoluzioni per sempre

• Nel contesto del fatto che solo tag e rami sono sufficienti per far sì che Git mantenga un commit in modo permanente

• Nel contesto dei recuperi FETCH_HEAD (recuperi diretti da URL tramite git fetch) perché sono immediatamente soggetti alla garbage collection

Uso quando eseguo un grande commit, soprattutto quando rimuovo più file dal repository .. dopo, i commit sono più veloci

Non è necessario utilizzarlo git gcmolto spesso, poiché git gc(Garbage collection) viene eseguito automaticamente su diversi comandi utilizzati di frequente:

git pull
git merge
git rebase
git commit

Fonte: best practice e FAQ su git gc