Rimuovere file dal repository git (storia)

StackOverflow https://stackoverflow.com/questions/2164581

Domanda

(risolto, vedere in fondo alla questione del corpo)
Cercando questo per lungo tempo ora, quello che ho fino ad ora è:

Praticamente lo stesso metodo, ma entrambe lasciare oggetti in file pack...Bloccato.
Quello che ho provato:

git filter-branch --index-filter 'git rm --cached --ignore-unmatch file_name'
rm -Rf .git/refs/original
rm -Rf .git/logs/
git gc

Hai ancora dei file nel pacchetto, e questo è come io la conosco: 

git verify-pack -v .git/objects/pack/pack-3f8c0...bb.idx | sort -k 3 -n | tail -3

E questo:

git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch file_name" HEAD
rm -rf .git/refs/original/ && git reflog expire --all &&  git gc --aggressive --prune

Lo stesso...

Provato git clone trucco, è rimosso alcuni file (~3000), ma il più grande file sono ancora lì...

Ho alcune grandi eredità file nel repository, ~200M, e io davvero non li vogliono lì...E non ho voglia di reimpostare il repository a 0 :(

SOLUZIONE:Questo è il modo più veloce per sbarazzarsi del file:

  1. di controllo .git/pranzo al-rif - il mio problema è che ho avuto c'è un refs/remotes/origin/master linea per un repository remoto, cancellare, altrimenti git non rimuovere tali file
  2. (opzionale) git verify-pack -v .git/objects/pack/#{pack-name}.idx | sort -k 3 -n | tail -5 - per controllare i file più grandi
  3. (opzionale) git rev-list --objects --all | grep a0d770a97ff0fac0be1d777b32cc67fe69eb9a98 - per verificare che cosa sono i file
  4. git filter-branch --index-filter 'git rm --cached --ignore-unmatch file_names' - per rimuovere un file da tutte le revisioni
  5. rm -rf .git/refs/original/ - per rimuovere git backup
  6. git reflog expire --all --expire='0 days' - per la scadenza di tutti gli oggetti sciolti
  7. git fsck --full --unreachable - per verificare se ci sono eventuali oggetti sciolti
  8. git repack -A -d - imballaggio
  9. git prune alla fine di rimuovere questi oggetti
È stato utile?

Soluzione

Non posso dire con certezza che non hanno accesso ai dati repository, ma credo che probabilmente ci sono uno o più arbitri confezionati ancora fanno riferimento a vecchi impegna da prima è stato eseguito git filter-branch. Questo spiegherebbe perché git fsck --full --unreachable non chiama il grande blob un oggetto irraggiungibile, anche se hai scaduta La reflog e rimosso gli arbitri originali (non imballate).

Ecco cosa farei (dopo git filter-branch e git gc sono stati fatti):

1) Assicurarsi arbitri originali sono andati:

rm -rf .git/refs/original

2) Scadenza tutte le voci reflog:

git reflog expire --all --expire='0 days'

3) Verificare la presenza di vecchi arbitri confezionati

Questo potrebbe essere potenzialmente ingannevole, a seconda di quanti refs al sacco che avete. Non so di qualsiasi comando Git che automatizzare questo, quindi penso che dovrete farlo manualmente. Eseguire un backup del .git/packed-refs. Ora modificare .git/packed-refs. Verificare la presenza di vecchi arbitri (in particolare, vedere se confezionato una delle arbitri da .git/refs/original). Se trovate qualche vecchi che non hanno bisogno di essere lì, eliminarle (rimuovere la riga per quella ref).

Dopo aver completato la pulizia del file packed-refs, vedere se git fsck nota gli oggetti irraggiungibili:

git fsck --full --unreachable

Se questo ha funzionato, e git fsck ora riporta la tua grande blob come irraggiungibile, si può passare alla fase successiva.

4) imballare l'archivio compresso (s)

git repack -A -d

Questo farà sì che gli oggetti irraggiungibili ottengono scompattato e soggiorno spacchettato.

5) Prune sciolti (non raggiungibile) oggetti

git prune

E che dovrebbe farlo. Git in realtà dovrebbe avere un modo migliore per gestire arbitri confezionati. Forse c'è un modo migliore che io non so. In assenza di un modo migliore, la modifica manuale del file packed-refs potrebbe essere l'unico modo per andare.

Altri suggerimenti

Mi consiglia di utilizzare la BFG Repo-Cleaner, un modo più semplice, veloce alternativa a git-filter-branch specificamente progettato per la riscrittura dei file dalla cronologia.Uno dei modi in cui si rende la vita più facile, qui, è che effettivamente gestisce tutti riferimenti per impostazione predefinita (tutti i tag, rami, roba come refs/remotes/origin/master, ecc), ma anche 10-50x più veloce.

Si consiglia di seguire attentamente questi passaggi qui: http://rtyley.github.com/bfg-repo-cleaner/#usage - ma il cuore di un po ' questo:scarica il BFG il vaso di (richiede Java 6 o superiore) ed eseguire questo comando:

$ java -jar bfg.jar  --delete-files file_name  my-repo.git

Qualsiasi file denominato file_name (che non è nella tua ultima commit) sarà sarà totalmente rimosso dall'archivio di storia.È quindi possibile utilizzare git gc per pulire via i morti, i dati:

$ git gc --prune=now --aggressive

Il BFG è generalmente molto più semplice da utilizzare rispetto git-filter-branch - le opzioni sono su misura per questi due casi:

  • Rimozione Pazzo Di File Di Grandi Dimensioni
  • Rimozione Password, Credenziali e altri Dati privati

Full disclosure:Io sono l'autore della BFG Repo-Cleaner.

Ho trovato questo per essere molto utile per quanto riguarda la rimozione di una cartella intera come sopra in realtà non mi aiuta: https://help.github.com/articles/remove-sensitive-data .

ho usato: 

git filter-branch -f --force \
--index-filter 'git rm -rf --cached --ignore-unmatch folder/sub-folder' \
--prune-empty --tag-name-filter cat -- --all

rm -rf .git/refs/original/
git reflog expire --expire=now --all
git gc --prune=now
git gc --aggressive --prune=now

Stavo cercando di liberarsi di un grosso file nella storia, e le risposte di cui sopra lavorato, fino a un certo punto. Il punto è: non funziona se si dispone di tag. Se il commit che contiene il file grande è raggiungibile da un tag, allora si avrebbe bisogno di regolare il comando del filtro-rami nel seguente modo: 

git filter-branch --tag-name-filter cat \
--index-filter 'git rm --cached --ignore-unmatch huge_file_name' -- \
--all --tags

See: Come faccio a rimuovere i file sensibili dalla storia di git

È possibile che questo avrà esito negativo se il file non esiste in un giro. In tal caso, l'interruttore '--ignore-unmatch' lo risolverà: 

git filter-branch -f --index-filter 'git rm --cached --ignore-unmatch <filename>' HEAD

Quindi, per ottenere tutti gli oggetti sciolti fuori dalla repostiry: 

git gc --prune='0 days ago'

Sono disponibili varie ragioni per una ancora grande formato git repo dopo git gc, in quanto non rimuovere tutti gli oggetti sciolti .

I dettagli detti motivi nel " ridurre il git repository dimensioni "

Ma un trucco per testare nel tuo caso sarebbe quello di clone la tua "puliti" Git repo e vedere se il clone ha la dimensione appropriata.

( ' 'pulito' pronti contro termine' essere quello in cui avete fatto applicare la filter-branch, e poi gc e prune)

Questo dovrebbe essere coperto dal comando git obliterate a Git Extra ( https://github.com/visionmedia/ git-extras ). 

git obliterate <filename>

Ho avuto lo stesso problema e ho trovato un grande esercitazione su GitHub che spiegare passo per passo come sbarazzarsi di file avete commesso accidentalmente.

Ecco un piccolo riassunto della procedura Cupcake suggerito.

Se si dispone di un file chiamato file_to_remove per rimuovere dalla storia: 

cd path_to_parent_dir

git filter-branch --force --index-filter \
  'git rm --cached --ignore-unmatch file_to_remove' \
  --prune-empty --tag-name-filter cat -- --all
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top