Listing e l'eliminazione di commit Git che sono sotto nessun ramo (penzoloni?)

Question

Ho un repository Git con un sacco di commit che sono sotto nessun ramo particolare, posso git show, ma quando cerco di rami lista che li contengono, si segnala nulla di nuovo.

Ho pensato che questo è il / tema albero commit penzoloni (come risultato di ramo -D), così ho potato il pronti contro termine, ma ho ancora vedere lo stesso comportamento dopo che:

$ git fetch origin

$ git fsck --unreachable
$ git fsck

Nessuna uscita, niente penzoloni (giusto?). Ma il commit esiste

$ git show 793db7f272ba4bbdd1e32f14410a52a412667042
commit 793db7f272ba4bbdd1e32f14410a52a412667042
Author: ...

e non è raggiungibile attraverso qualsiasi ramo come

$ git branch --contains 793db7f272ba4bbdd1e32f14410a52a412667042

non fornisce alcuna uscita.

Che cosa è esattamente lo stato di che commettono? Come posso elencare tutti i commit in uno stato simile? Come posso cancellare commit come quelli?

Answer 1

  

Nessuna uscita, niente penzoloni (giusto?)

Si noti che impegna di cui dal reflog sono considerati raggiungibile.

  

Che cosa è esattamente lo stato di che commettono? Come posso elencare tutti i commit con simile stato

Passo --no-reflogs per convincere git fsck per mostrarli a voi.

  

Come faccio a eliminare commit come quelli?

Una volta che le voci reflog sono scaduti, questi oggetti saranno poi anche essere ripuliti dai git gc.

scadenza è regolata dalle impostazioni gc.pruneexpire, gc.reflogexpire e gc.reflogexpireunreachable. Cf. git help config .

I valori di default sono tutti abbastanza ragionevole.

Answer 2

Per rimuovere tutti i commit penzolanti e di quelli raggiungibili dalle reflogs fare questo:

git reflog expire --expire-unreachable=now --all
git gc --prune=now

Ma essere certi che questo è ciò che si desidera. Vi consiglio di leggere le pagine man, ma qui è il succo del discorso:

git gcremoves irraggiungibili oggetti (impegna, alberi, blob (file)). Un oggetto non è raggiungibile se non è parte della storia di qualche ramo. In realtà è un po 'più complicato:

git gc fa alcune altre cose, ma non sono rilevanti qui e non pericoloso.

gli oggetti non raggiungibili che sono più giovane di due settimane non vengono rimossi in modo da utilizzare --prune=now che significa "rimuovere gli oggetti non raggiungibili che sono stati creati prima d'ora".

Gli oggetti possono anche essere raggiunto attraverso la reflog. Mentre rami registrano la storia di alcuni progetti, reflogs registrare la storia di questi rami. Se emendare, reimpostare ecc impegna vengono rimossi dalla storia ramo, ma git li tiene in giro nel caso in cui ci si rende conto di aver commesso un errore. Reflogs sono un modo conveniente per scoprire cosa distruttivi (e altre) le operazioni sono state eseguite su un ramo (o della testa), rendendo più facile per annullare un'operazione distruttiva.

Quindi dobbiamo anche rimuovere i reflogs per rimuovere tutto ciò in realtà non raggiungibile da un ramo. Lo facciamo con scadenza reflogs --all. Anche in questo caso git mantiene un po 'dei reflogs per gli utenti a proteggere in modo che ancora una volta deve dire di non farlo:. --expire-unreachable=now

Da quando uso principalmente la reflog per recuperare da operazioni distruttive io di solito uso --expire=now invece, che zaps completamente i reflogs.

Answer 3

Ho avuto lo stesso problema, ancora dopo aver seguito tutti i consigli in questa discussione:

git reflog expire --expire-unreachable=now --all
git gc --prune=now
git fsck --unreachable --no-reflogs   # no output
git branch -a --contains <commit>     # no output
git show <commit>                     # still shows up

Se non è un reflog e non un ramo, ... deve essere un tag

git tag                             # showed several old tags created before the cleanup

Ho rimosso il tag con git tag -d <tagname> e rifatto la pulizia, e le vecchie commit c'erano più.

Answer 4

git branch --contains 793db7f272ba4bbdd1e32f14410a52a412667042

probabilmente solo bisogno di essere

git branch -a --contains 793db7f272ba4bbdd1e32f14410a52a412667042

a riferire anche sui rami da telecomandi

Answer 5

Ho avuto un problema simile. Mi sono imbattuto git branch --contains <commit>, ed è tornato senza uscita, proprio come nella questione.

Ma anche dopo l'esecuzione

git reflog expire --expire-unreachable=now --all
git gc --prune=now

Il mio commettere era ancora accessibile utilizzando git show <commit>. Questo perché uno dei commit nel suo staccato penzolava "ramo" / è stato taggato. Ho rimosso il tag, corse di nuovo i comandi di cui sopra, ed ero d'oro. git show <commit> fatal: bad object <commit> tornato - esattamente quello che mi serviva. Speriamo che questo aiuta a qualcun altro che era bloccato come lo ero io.

Answer 6

default git gc --prune=<date> potare gli oggetti più vecchio di due settimane fa. È possibile impostare una data più recente. Ma, comandi Git che creano oggetti sciolti generalmente funzioneranno git gc --auto (che perdono prugne oggetti se il loro numero supera il valore della variabile di configurazione gc.auto).

Sei sicuro di voler eliminare questi impegna? impostazione predefinita di gc.auto farà in modo che gli oggetti sciolti non occupano una quantità ragionevole di memoria, e memorizzare oggetti sciolti per una certa quantità di tempo è generalmente una buona idea. In questo modo, se vi rendete conto che il vostro domani ramo cancellato conteneva un commit avete avuto bisogno, è possibile recuperarlo.

Answer 7

ho accidentalmente colpito la stessa situazione e trovato il mio stashes contengono riferimento al irraggiungibile impegnarsi, e quindi la presunta irraggiungibile impegnano era raggiungibile da stashes.

Queste erano quello che ho fatto per renderla veramente irraggiungibile.

git stash clear
git reflog expire --expire-unreachable=now --all
git fsck --unreachable
git gc --prune=now