Esiste un modo per riparare il mio repository con la cronologia dei commit in tatto.Registro di Git: oggetto fatale [sha1] è danneggiato
# git log
fatal: object 01aeb2bf2e93b238f0e0422816b3e55518321ae7 is corrupted
Dalla lettura del link di seguito sembra che lo avrò zappato e ricomincio.
http://www.miek.nl/s/7e76eadefe/
Avete cloni di questo repository altrove? Si consiglia di leggere this post da Linus Torvalds per ripristinare quell'oggetto danneggiato, presupponendo che l'oggetto danneggiato sia un blob (contenuto del file).
Nessun clone. L'ho appena impostato ieri. Quindi avevo solo 10 commit. Ho finito per ricominciare da capo. Ma sicuramente lo spingerò da un'altra parte alla fine di ogni giorno. Lezione appresa. Ancora felice di essere fuori svn. Git è veloce! – Keyo
Sarebbe utile includere la sintesi del messaggio nella tua risposta, solo in caso, per esempio, kernal.org viene mai hackerato e non è in linea :( – SpoonMeiser
Mi sono ritrovato nella stessa situazione, probabilmente a causa di un arresto improprio della macchina virtuale in cui stavo lavorando. C'erano circa 10 oggetti in .git/oggetti con lunghezza zero. Per quello che posso dire, i file del codice sorgente vero e proprio andavano bene, solo il repository era stato disinfettato.
$ git status
fatal: object fbcf234634ee04f8406cfd250ce5ab8012f92b08 is corrupted
Per alcuni suggerimenti che ho visto altrove (tra cui il post di Linus di cui sopra), ho provato a posizionare gli oggetti danneggiati git si lamentava da .git/oggetti altrove. Quando si era trasferito tutti loro, ho ottenuto:
$ git status
fatal: bad object HEAD
Dopo circa un'ora di usare Google e provando varie soluzioni, ho rinunciato e ha iniziato una nuova copia di lavoro utilizzando 'clone git' a tirare dall'origine (che era circa 2 ore dietro la mia copia di lavoro). Ho quindi utilizzato rsync -rC (-C esclude i file SCM) per copiare i file modificati dalla copia funzionante incasinata alla mia nuova copia di lavoro.
Grazie! Sembra funzionare per me .. disastro evitato – DevX
La stessa cosa qui corruzione VM. rsync ha funzionato perfettamente - niente perso, solo il registro che è stato facile da ricreare.Grazie! –
Si potrebbe anche provare a ripristinare questi oggetti semplicemente copiandoli da altri repository.
La macchina virtuale si è arrestata in modo anomalo durante la registrazione di un commit push, quindi gli oggetti sono stati archiviati in modo sicuro su un computer locale. Li ho scaricati sulla macchina virtuale e voilà - git fsck non emette errori.
Basta eliminare l'oggetto danneggiato di cui si lamenta git. Sono stato in grado di risolvere lo stesso problema solo ora in questo modo.
fatal: object 985a4870e7d890b314d2794377045a8b007c7925 is corrupted
Per l'errore di cui sopra, sono stato in grado di trovare l'oggetto corrispondente a:
project_directory/.git/objects/98/5a4870e7d890b314d2794377045a8b007c7925
dove si può vedere il file è 0 byte e l'eliminazione ha permesso l'operazione di recupero per iniziare a lavorare.
Presumibilmente il precedente recupero è stato interrotto, lasciando l'oggetto danneggiato con dimensione = 0 byte.
bizzarro che funzioni davvero, un po 'come calciare il televisore per chiarire la staticità! –
Non ha funzionato per me e suona male idea considerando le diverse istruzioni di Torvalds su come riparare l'oggetto corrotto (elencato sopra nella risposta) –
Non ha funzionato neanche per me. Il mio oggetto
avuto lo stesso problema, a seconda di quale comando git mi sono imbattuto, è finito con il messaggio:
fatal: object <hash> is corrupted
non ho avuto una copia di backup e non volevo perdere il mio impegna, così ho deciso di provare la soluzione di Jase e rimosso il file 0 lunghezza ho avuto: .git/objects/00/<hash> Poi ho ottenuto lo stesso:
$ git status
fatal: bad object HEAD
Poi, ho cercato di sapere che cosa era sbagliato e guardato in .git/refs/heads/master dove ho avuto l'hash.
ho guardato in .git/logs/refs/head/master e ha trovato le linee come questo:
<old commit> <new commit> <author> <timestamp> commit: <commit message>
ho rimosso l'ultima riga (che aveva =) e incollati di questa linea in .git/refs/heads/master, cancellando il suo contenuto
ero allora in grado di impegnarsi con successo.
Ho avuto lo stesso problema. Ho notato che non ero loggato come root. Quando ho effettuato il login come root, sono stato in grado di controllare il log senza il segno di errore.
per consolidare questo buon stato, ho fatto questo:
git add .
git commit -a -m "stabilize git"
Sono uscito dalla radice e provato tirando da un client. Ha funzionato per me in seguito.
Quando ho aggiunto e commesso, sapevo che stavo bene con quello che c'era nella directory. Non ho avuto cambiamenti visibili tramite "git status".
Devo aggiungere che la causa principale di questo problema era il danneggiamento del disco sulla mia macchina virtuale, che non si arrestava correttamente. – Keyo