Perché esistono ancora file di grandi dimensioni nel mio file pack, dopo averli strofinati con il filtro-ramo?

Question

Ho riscritto la cronologia del mio repository per rimuovere alcuni file FLV di grandi dimensioni utilizzando git filter-branch. Io in primo luogo seguito l'articolo articolo Github su removing sensitive data e istruzioni simili trovate altrove su Internet:

Rimozione del grande FLV:

git filter-branch --index-filter 'git rm --cached --ignore-unmatch public/video/*.flv' --prune-empty -- --all 

Rimozione gli arbitri originali:

Cancellare il reflog:

git reflog expire --expire=now --all 

Potare oggetti non raggiungibili:

git gc --prune=now 

Aggressivly potatura gli oggetti non raggiungibili:

git gc --aggressive --prune=now 

cose reimballaggio:

git repack -A -d 

E la mia gitdir è ancora 205 MB, conteneva quasi interamente in un unico packfile:

$ du -h .git/objects/pack/* 
284K .git/objects/pack/pack-f72ed7cee1206aae9a7a3eaf75741a9137e5a2fe.idx 
204M .git/objects/pack/pack-f72ed7cee1206aae9a7a3eaf75741a9137e5a2fe.pack 

Utilizzando this script, posso vedere che il file FLV ho rimosso sono ancora contenuti nella confezione:

All sizes are in kB's. The pack column is the size of the object, compressed, inside the pack file. 
size pack SHA          location 
17503 17416 1be4132fa8d91e6ce5c45caaa2757b7ea87d87b0 public/video/XXX_FINAL.flv 
17348 17261 b7aa83e187112a9cfaccae9206fc356798213c06 public/video/YYY_FINAL.flv 
.... 

clonazione del repository tramite git clone --bare my-repo rendimenti my-repo.git che è anche 205MB di dimensione.

Cosa posso fare per rimuovere questi oggetti (presumibilmente) non referenziati dal pacchetto e ridimensionare il mio repository alla dimensione che sarebbe se non fossero mai stati impegnati? Se sono ancora referenziati in qualche modo, c'è un modo per dire dove?

Aggiornamento

momento di tentare di eseguire nuovamente git filter-branch, ho ricevuto questo avviso:

Cannot create a new backup. 
A previous backup already exists in refs/original/ 
Force overwriting the backup with -f 

ho verificato che ci fossero non arbitri in .git/refs/original, infatti, la directory non ha fatto esiste del tutto. C'è qualche altro modo che git memorizza i refs, di cui non so nulla?

Answer 1

Su clonazione una nuova copia del repository, sono stato in grado di eseguire i comandi esattamente come sopra, e ottenere il risultato desiderato: Il mio elenco .git è stato ridotto da 205 MB fino a 20 MB, e la grande FLV i file sono stati rimossi in modo pulito dal file pack.

Il primo tentativo è stato eseguito anche su un nuovo clone a cui non avevo apportato alcuna modifica, quindi non ho una spiegazione soddisfacente del motivo per cui i file FLV hanno continuato a rimanere all'interno del file pack.

ho inizialmente presentato la risposta qui sotto, pensando che avevo causato un problema eseguendo git repack -a prima di rimuovere .git/refs/original, causando gli arbitri originali per diventare ricco in modo che quando ho fatto rimuovere .git/refs/original non v'è stato alcun effetto; i miei ref originali continuerebbero a fare riferimento ai file FLV di grandi dimensioni. Questo non sembra reggere, comunque. Esecuzione dei comandi di cui sopra su una copia appena clonata del repository con l'aggiunta di git repack -a subito dopo git filter-branch non sembra influenzare l'esito - i file FLV vengono ancora eliminati dal packfile. Non ho motivo di credere che questo sia rilevante per il problema originale.

---

C'è qualche altro modo in cui Git arbitri, che non conoscono?

C'è. Si scopre che non ero del tutto sincero sull'ordine dei comandi come elencato sopra. Avevo corso git repack -aprima esecuzione rm -rf .git/refs/original, e Git avevo preparato gli arbitri di distanza (da stabilire dove; sperimentando ora). Quando ho eseguito rm -rf .git/refs/original, non è stato rimosso nulla. git gc non era in grado di compattare il mio packfile perché ho fatto ancora avere persistente riferimenti ai vecchi file a causa delle imballati refs/original arbitri.