2015-01-09 17 views
9

Recentemente ho trovato un limite di dimensioni con il mio repository Bitbucket. Ho seguito le innumerevoli altre domande che hanno risposto a come ripulire il repository git e ho finito con l'utilizzo di BFG per rimuovere alcuni cattivi commit.Come ripulire la spazzatura nel repository git remoto

Questo ha funzionato benissimo, tuttavia, ho notato che dopo aver eseguito un conteggio del git, c'era una grande quantità di spazio nella spazzatura. Quindi ho eseguito un semplice git gc. Tuttavia, questo non ha fatto nulla per ripulire la spazzatura.

Dopo qualche scavo ho trovato il seguente comando:

git -c gc.reflogExpire=0 -c gc.reflogExpireUnreachable=0 -c gc.rerereresolved=0 \ 
-c gc.rerereunresolved=0 -c gc.pruneExpire=now gc "[email protected]" 

L'esecuzione di questo ha portato alla spazzatura di essere ripulito localmente. Tuttavia, ho ancora il problema del repository remoto. Devo ora ottenere Bitbucket per eseguire questo comando sul mio repository remoto, o c'è un modo per spingere questa modifica al repository?

+2

Non posso parlare per bitbucket, ma in generale, i cloni nude non tenere reflogs; non ci sarebbero nemmeno dati rerere. In genere devi solo aggiornare gli errori sul telecomando e attivare un gc lì. – torek

risposta

7

Se qualcun altro lo sta riscontrando, la risposta si è rivelata positiva.

supporto Bitbucket eseguito il seguente:

bash-4.1$ git reflog expire --expire="1 hour" --all 
bash-4.1$ git reflog expire --expire-unreachable="1 hour" --all 
bash-4.1$ git prune --expire="1 hour" -v 
bash-4.1$ git gc --aggressive --prune="1 hour" 

La prima e dopo ridotto le dimensioni repo remoto da oltre 2 GB, a meno di 1 GB.

14

Noi che abbiamo avuto lo stesso problema di oggi e siamo riusciti a risolverlo senza contattare il supporto Bitbucket, come qui di seguito. Notare che il metodo scarta l'ultimo commit dal repository, quindi probabilmente si desidera avere il suo backup.

Bitbucket ha riferito che il nostro repo era di circa 2,1 GB, mentre quando clonato, ci sono voluti solo circa 250 MB a livello locale. Da ciò abbiamo concluso che è molto probabile che si tratti di file di grandi dimensioni in commit non raggiungibili (grazie a this answer).

Questo è il modo di vedere irraggiungibile impegna a livello locale, dove noi non prendiamo in considerazione raggiungibilità via reflog:

git fsck --unreachable --no-reflog

A livello locale, i commit irraggiungibili possono essere puliti con:

git reflog expire --expire-unreachable="now" --all 
git prune --expire="now" -v 
git gc --aggressive --prune="now" 

Tuttavia, non possiamo eseguire nessuno di questi comandi da remoto su Bitbucket. Ma, dicono sul the page about reducing repo size (sezione Rimuovere la limitazione repository) che corrono git gc stessi in risposta a fare git reset --hard HEAD~1 (che scarti ultima impegnano) seguito da git push -f. Inoltre, si dice nel Garbage sezione raccolta dei dati morti che si può provare la sequenza: git reflog expire --expire=now --all, git gc --prune=now, git push --all --force. Dato tutto questo, ho deciso di provare la seguente localmente, sperando che aveva tagliato fuori la reflog e fare una prugna a livello locale, e poi spingerli al repository remoto Bitbucket, su cui avrebbe cominciato un gc:

git reflog expire --expire-unreachable="30m" --all 
git prune --expire="30m" -v 
git gc --prune="30m" 
git reset --hard HEAD~1 
git push -f 

Questo ha funzionato, formato di deposito immediatamente è andato da 2,1 GB a ca. 250MB.:)

Si noti che il parametro tempo di scadenza/scadere-irraggiungibile/prune imposta il punto di misura scadenza cut-off da ora di nuovo. Quindi ad es. "now" significa espire/prune tutto e "30m" significa tranne che per le modifiche negli ultimi 30 minuti.

+0

il 'git reset --hard HEAD ~ 1' e il trucco 'git push -f' è polvere d'oro, grazie! – Liam

+1

Funziona su qualsiasi ramo o è necessario eseguire il reset su master? –

+0

Lavora come un incantesimo, grazie –

Problemi correlati