come risolvere l’errore GIT: il file object è vuoto?

Quando provo a commettere modifiche, ottengo questo errore:

error: object file .git/objects/31/65329bb680e30595f242b7c4d8406ca63eeab0 is empty fatal: loose object 3165329bb680e30595f242b7c4d8406ca63eeab0 (stored in .git/objects/31/65329bb680e30595f242b7c4d8406ca63eeab0) is corrupt 

Qualche idea su come risolvere questo errore?

MODIFICARE

Ho provato git fsck che ho:

 error: object file .git/objects/03/dfd60a4809a3ba7023cbf098eb322d08630b71 is empty fatal: loose object 03dfd60a4809a3ba7023cbf098eb322d08630b71 (stored in .git/objects/03/dfd60a4809a3ba7023cbf098eb322d08630b71) is corrupt 

Ho avuto un problema simile. Il mio portatile ha esaurito la batteria durante un’operazione git. Boo.

Non ho avuto alcun backup. (NB Ubuntu One non è una soluzione di backup per git, sovrascriverà in modo utile il tuo repository sano con quello corrotto.)

Per i maghi di Git, se questo fosse un brutto modo per risolverlo, per favore lascia un commento. Tuttavia, ha funzionato per me … almeno temporaneamente.

Passaggio 1: eseguire un backup di .git (infatti lo faccio tra ogni passaggio che cambia qualcosa, ma con un nuovo nome di copia, ad esempio .git-old-1, .git-old-2, ecc.) :

 cp -a .git .git-old 

Passaggio 2: Esegui git fsck --full

 [email protected]:~/workspace/mcmc-chapter$ git fsck --full error: object file .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e is empty fatal: loose object 8b61d0135d3195966b443f6c73fb68466264c68e (stored in .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e) is corrupt 

Passaggio 3: rimuovere il file vuoto. Ho capito cosa diamine; è vuoto comunque.

 [email protected]:~/workspace/mcmc-chapter$ rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e rm: remove write-protected regular empty file `.git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e'? y 

Passaggio 3: Esegui nuovamente git fsck . Continua a cancellare i file vuoti. Puoi anche effettuare il cd nella directory .git ed eseguire find . -type f -empty -delete -print find . -type f -empty -delete -print per rimuovere tutti i file vuoti. Alla fine git ha iniziato a dirmi che stava effettivamente facendo qualcosa con le directory object:

 [email protected]:~/workspace/mcmc-chapter$ git fsck --full Checking object directories: 100% (256/256), done. error: object file .git/objects/e0/cbccee33aea970f4887194047141f79a363636 is empty fatal: loose object e0cbccee33aea970f4887194047141f79a363636 (stored in .git/objects/e0/cbccee33aea970f4887194047141f79a363636) is corrupt 

Passo 4: Dopo aver cancellato tutti i file vuoti, alla fine sono arrivato a git fsck attualmente in esecuzione:

 [email protected]:~/workspace/mcmc-chapter$ git fsck --full Checking object directories: 100% (256/256), done. error: HEAD: invalid sha1 pointer af9fc0c5939eee40f6be2ed66381d74ec2be895f error: refs/heads/master does not point to a valid object! error: refs/heads/master.u1conflict does not point to a valid object! error: 0e31469d372551bb2f51a186fa32795e39f94d5c: invalid sha1 pointer in cache-tree dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2 missing blob 8b61d0135d3195966b443f6c73fb68466264c68e missing blob e89896b1282fbae6cf046bf21b62dd275aaa32f4 dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a missing blob caab8e3d18f2b8c8947f79af7885cdeeeae192fd missing blob e4cf65ddf80338d50ecd4abcf1caf1de3127c229 

Passaggio 5: prova git reflog . Fallito perché il mio HEAD è rotto.

 [email protected]:~/workspace/mcmc-chapter$ git reflog fatal: bad object HEAD 

Passaggio 6: Google. Trova questo . Ottieni manualmente le ultime due righe del reflog:

 [email protected]:~/workspace/mcmc-chapter$ tail -n 2 .git/logs/refs/heads/master f2d4c4868ec7719317a8fce9dc18c4f2e00ede04 9f0abf890b113a287e10d56b66dbab66adc1662d Nathan VanHoudnos  1347306977 -0400 commit: up to p. 24, including correcting spelling of my name 9f0abf890b113a287e10d56b66dbab66adc1662d af9fc0c5939eee40f6be2ed66381d74ec2be895f Nathan VanHoudnos  1347358589 -0400 commit: fixed up to page 28 

Passaggio 7: Si noti che dal passaggio 6 abbiamo appreso che l’HEAD sta attualmente puntando all’ultimo commit. Quindi proviamo a dare un’occhiata al commit genitore:

 [email protected]:~/workspace/mcmc-chapter$ git show 9f0abf890b113a287e10d56b66dbab66adc1662d commit 9f0abf890b113a287e10d56b66dbab66adc1662d Author: Nathan VanHoudnos  Date: Mon Sep 10 15:56:17 2012 -0400 up to p. 24, including correcting spelling of my name diff --git a/tex/MCMC-in-IRT.tex b/tex/MCMC-in-IRT.tex index 86e67a1..b860686 100644 --- a/tex/MCMC-in-IRT.tex +++ b/tex/MCMC-in-IRT.tex 

Ha funzionato!

Passaggio 8: ora è necessario puntare HEAD su 9f0abf890b113a287e10d56b66dbab66adc1662d.

 [email protected]:~/workspace/mcmc-chapter$ git update-ref HEAD 9f0abf890b113a287e10d56b66dbab66adc1662d 

Che non si lamentava.

Passo 9: guarda cosa dice fsck:

 [email protected]:~/workspace/mcmc-chapter$ git fsck --full Checking object directories: 100% (256/256), done. error: refs/heads/master.u1conflict does not point to a valid object! error: 0e31469d372551bb2f51a186fa32795e39f94d5c: invalid sha1 pointer in cache-tree dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2 missing blob 8b61d0135d3195966b443f6c73fb68466264c68e missing blob e89896b1282fbae6cf046bf21b62dd275aaa32f4 dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a missing blob caab8e3d18f2b8c8947f79af7885cdeeeae192fd missing blob e4cf65ddf80338d50ecd4abcf1caf1de3127c229 

Passo 10: Il puntatore sha1 non valido nella cache-tree sembrava come se provenisse da un (indice) ormai obsoleto. Quindi l’ho ucciso e resettato il repository.

 [email protected]:~/workspace/mcmc-chapter$ rm .git/index [email protected]:~/workspace/mcmc-chapter$ git reset Unstaged changes after reset: M tex/MCMC-in-IRT.tex M tex/recipe-example/build-example-plots.R M tex/recipe-example/build-failure-plots.R 

Step 11: Guardando di nuovo il fsck …

 [email protected]:~/workspace/mcmc-chapter$ git fsck --full Checking object directories: 100% (256/256), done. error: refs/heads/master.u1conflict does not point to a valid object! dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2 dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a 

I blob penzolanti non sono errori . Non mi interessa master.u1conflict, e ora che funziona non voglio più toccarlo!

Passaggio 12: recuperando le mie modifiche locali:

 [email protected]:~/workspace/mcmc-chapter$ git status # On branch master # Changes not staged for commit: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: tex/MCMC-in-IRT.tex # modified: tex/recipe-example/build-example-plots.R # modified: tex/recipe-example/build-failure-plots.R # < ... snip ... > no changes added to commit (use "git add" and/or "git commit -a") [email protected]:~/workspace/mcmc-chapter$ git commit -a -m "recovering from the git fiasco" [master 7922876] recovering from the git fiasco 3 files changed, 12 insertions(+), 94 deletions(-) [email protected]:~/workspace/mcmc-chapter$ git add tex/sept2012_code/example-code-testing.R [email protected]:~/workspace/mcmc-chapter$ git commit -a -m "adding in the example code" [master 385c023] adding in the example code 1 file changed, 331 insertions(+) create mode 100644 tex/sept2012_code/example-code-testing.R 

Quindi spero che possa essere di qualche utilità per le persone in futuro. Sono contento che abbia funzionato.

I file object git sono andati corrotti (come indicato anche in altre risposte). Questo può accadere durante arresti anomali della macchina, ecc.

Ho avuto la stessa cosa. Dopo aver letto le altre risposte migliori qui ho trovato il modo più rapido per correggere il repository git rotto con i seguenti comandi (eseguito nella directory di lavoro git che contiene la cartella .git ):

(Assicurati di eseguire prima il backup della cartella del repository git!)

 find .git/objects/ -type f -empty | xargs rm git fetch -p git fsck --full 

Questo rimuoverà prima tutti i file object vuoti che causano il danneggiamento del repository nel suo insieme, quindi recupereranno gli oggetti mancanti (così come le ultime modifiche) dal repository remoto, e quindi eseguiranno un controllo completo sull’archivio oggetti . Che, a questo punto, dovrebbe riuscire senza errori (potrebbero esserci ancora alcuni avvertimenti!)

PS. Questa risposta suggerisce di avere una copia remota del repository git da qualche parte (ad esempio su GitHub) e il repository rotto è il repository locale che è legato al repository remoto che è ancora intatto. Se questo non è il caso, quindi non tentare di risolvere il problema nel modo che raccomando.

Ho risolto questo rimuovendo i vari file vuoti che git fsck stava rilevando, e quindi eseguendo una semplice estrazione git.

Trovo deludente che ora anche i filesystem implementino il journaling e altre tecniche “transazionali” per mantenere il fs sano, git può arrivare a uno stato corrotto (e non essere in grado di recuperare da solo) a causa di un’interruzione dell’alimentazione o dello spazio sul dispositivo.

Questo errore mi succede quando spingo il mio commit e il mio computer si blocca. Ecco come ho risolto il problema.


Passi da sistemare

 git status 

mostra il file object vuoto / corrotto

 rm .git/objects/08/3834cb34d155e67a8930604d57d3d302d7ec12 

rimuoverla

 git status 

Sono diventato fatal: bad object HEAD messaggio fatal: bad object HEAD

 rm .git/index 

Rimuovo l’ index per il reset

 git reset 

fatale: imansible analizzare l’object “HEAD”.

 git status git pull 

solo per controllare che cosa sta succedendo

 tail -n 2 .git/logs/refs/heads/MY-CURRENT-BRANCH 

stampa le ultime 2 righe tail -n 2 del ramo log per mostrare il mio ultimo commit hash

 git update-ref HEAD 7221fa02cb627470db163826da4265609aba47b2 

Prendo l’ultimo commit hash

 git status 

mostra tutto il mio file come deleted perché ho rimosso il file .git/index

 git reset 

continua con il reset

 git status 

verifica la mia correzione


Nota: i passaggi iniziano quando sono atterrato su questa domanda e ho usato le risposte come riferimento.

Ho appena avuto lo stesso problema: dopo aver estratto il repository remoto, quando ho fatto uno stato git ho ricevuto: “errore: il file object (…) è vuoto” “fatale: object sciolto (…) è danneggiato”

Il modo in cui ho risolto questo era:

  1. git stash
  2. rimuovendo il file git per errore (non è sicuro che sia necessario)
  3. smettila di fumare

Non so esattamente cosa sia successo, ma quelle istruzioni sembravano rendere tutto pulito.

Perché devo riavviare regolarmente la mia VM, quindi in qualche modo questo problema mi capita molto spesso. Dopo alcune volte, mi sono reso conto che non riesco a ripetere il processo descritto da @ Nathan-Vanhoudnos ogni volta che succede, sebbene funzioni sempre. Quindi ho capito la seguente soluzione più veloce.

Passo 1

Sposta l’intero repository in un’altra cartella.

 mv current_repo temp_repo 

Passo 2

Clona nuovamente il repository dall’origine.

 git clone source_to_current_repo.git 

Passaggio 3

Rimuovi tutto sotto il nuovo repository tranne la cartella .git .

Passaggio 4

Sposta tutto da temp_repo al nuovo repository tranne la cartella .git .

Passaggio 5

Rimuovere il temp_repo , e abbiamo finito.

Dopo alcune volte, sono sicuro che puoi fare queste procedure molto velocemente.

  1. mv la tua cartella app per fare il backup, cioè mv app_folder app_folder_bk (è come una pila git )
  2. git clone your_repository
  3. Finalmente,. Apri uno strumento di fusione (utilizzo meld diff viewer linux o Winmerge Windows) e copia le modifiche da destra ( app_folder_bk ) a sinistra (nuova cartella_app ) (è come se si applicasse git stash ).

È tutto. Forse non è il modo migliore, ma penso che sia così pratico.

Nel mio caso, questo errore si è verificato perché stavo scrivendo il messaggio di commit e il mio notebook spento.

Ho fatto questi passaggi per correggere l’errore:

  • git checkout -b backup-branch # Crea un ramo di backup
  • git reset --hard HEAD~4 # Ripristina il commit dove tutto funziona correttamente. Nel mio caso, ho dovuto eseguire 4 commit nella testa, cioè fino a quando la mia testa non si trovava al punto prima di digitare il messaggio di commit. Prima di fare questo passaggio, copia l’hash dei commit che resetterai, nel mio caso ho copiato l’hash degli ultimi 4 commit
  • git cherry-pick # Cherry seleziona i commit resettati (nel mio caso sono 4 commit, quindi ho fatto questo passaggio 4 volte) dal vecchio ramo al nuovo ramo.
  • git push origin backup-branch # Premere il nuovo ramo per assicurarsi che tutto funzioni correttamente
  • git branch -D your-branch # Elimina il branch localmente (‘your-branch’ è il ramo con problemi)
  • git push origin :your-branch # Elimina il ramo da remoto
  • git branch -m backup-branch your-branch # Rinominare il ramo di backup per avere il nome del ramo che ha avuto il problema
  • git push origin your-branch # Spingi il nuovo ramo
  • git push origin :backup-branch # Elimina il ramo di backup da remoto

Ecco un modo molto semplice e veloce per affrontare questo problema SE si ha un repository locale con tutti i rami e commit necessari, e se si sta bene con la creazione di un nuovo repository (o eliminando il repository del server e facendone uno nuovo al suo posto):

  1. Crea un nuovo repository vuoto sul server (o elimina il vecchio repository e creane uno nuovo al suo posto)
  2. Cambia l’URL remoto della tua copia locale per puntare all’URL remoto del nuovo repository.
  3. Spingere tutti i rami dal repository locale al nuovo repository del server.

Questo conserva tutta la cronologia dei commit e i rami che hai avuto nel repository locale.

Se hai dei collaboratori sul repository, allora penso che in molti casi tutti i tuoi collaboratori debbano cambiare anche l’URL remoto del loro repository locale, e opzionalmente premere qualsiasi commit che hanno che il server non ha.

Questa soluzione ha funzionato per me quando mi sono imbattuto in questo stesso problema. Ho avuto un collaboratore. Dopo aver spinto il mio repo locale al nuovo repository remoto, ha semplicemente cambiato il suo repository locale per puntare all’URL repo remoto e tutto ha funzionato bene.

Suppongo che tu abbia un telecomando con tutte le modifiche pertinenti già inviate ad esso. Non mi interessavano le modifiche locali e volevo semplicemente evitare di cancellare e riavviare un ampio repository. Se hai importanti cambiamenti locali potresti voler essere più attento.

Ho avuto lo stesso problema dopo che il mio laptop si è schiantato. Probabilmente perché era un grande repository avevo parecchi file object corrotti, che apparivano solo uno alla volta quando chiamavo git fsck --full , così ho scritto una piccola shell one-liner per eliminare automaticamente uno di loro:

$ sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`

  • 2>&1 reindirizza il messaggio di errore a stdout per poterlo fare
  • Opzioni di grep utilizzate:
    • -o restituisce solo la parte di una riga che corrisponde effettivamente
    • -E consente regex avanzate
    • -m 1 assicurati che venga restituita solo la prima corrispondenza
    • [0-9a-f]{2} corrisponde a qualsiasi carattere compreso tra 0 e 9 e a e f se due di essi si verificano insieme
    • [0-9a-f]* corrisponde a qualsiasi numero di caratteri tra 0 e 9 e a e f che si verificano contemporaneamente

Elimina solo un file alla volta, quindi potresti chiamarlo in un ciclo come:

$ while true; do sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`; done

Il problema è che non produce più nulla di utile quindi non sai quando è finito (non dovrebbe fare nulla di utile dopo un po ‘di tempo)

Per “aggiustare” questo ho appena aggiunto una chiamata di git fsck --full dopo ogni round in questo modo: $ while true; do sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`; git fsck --full; done $ while true; do sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`; git fsck --full; done

Ora è circa la metà più veloce, ma emette il suo “stato”.

Dopo questo, ho giocato con alcuni suggerimenti in questo thread e finalmente sono arrivato al punto in cui avrei potuto git stash e git stash drop un sacco di cose rotte.

primo problema risolto

Successivamente ho avuto ancora il seguente problema: unable to resolve reference 'refs/remotes/origin/$branch': reference broken che potrebbe essere risolto da $ rm \repo.git\refs\remotes\origin\$branch

$ git fetch

Allora ho fatto un $ git gc --prune=now

$ git remote prune origin

per buona misura e

git reflog expire --stale-fix --all

per eliminare l’ error: HEAD: invalid reflog entry $blubb quando si esegue git fsck --full .

Incontro lo stesso problema e uso un modo molto semplice per risolverlo. Ho scoperto che quei file mancanti esistevano sul computer del mio compagno di squadra.

Ho copiato questi file uno per uno su un server git (9 file in totale) e questo ha risolto il problema.

Andiamo semplice .. solo caso hai caricato l’origine su remoto git repo

  1. Esegui il backup del tuo .git
  2. controlla il tuo idiota

     git fsck --full 
  3. rimuovi il file object vuoto (tutto)

     rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e 
  4. controlla di nuovo il tuo git.

     git fsck --full 
  5. estrai la tua fonte da git remoto

     git pull origin master 

Copia tutto (nella cartella contenente il file .git) in un backup, quindi elimina tutto e riavvia. Assicurati di avere a portata di mano il git remote:

 git remote -v origin [email protected]:rwldrn/idiomatic.js.git (fetch) origin [email protected]:rwldrn/idiomatic.js.git (push) 

Poi

 mkdir mygitfolder.backup cp mygitfolder/* mygitfolder.backup/ cd mygitfolder rm -r * .git* git init git remote add origin [email protected]:rwldrn/idiomatic.js.git 

Quindi unisci i nuovi file manualmente e prova a tenere acceso il computer.

Ho avuto lo stesso problema dopo aver controllato il master da un ramo pulito. Dopo un po ‘ho riconosciuto molti file modificati in master. Non so perché sono stati lì, dopo essere passati da un ramo pulito. Ad ogni modo, perché i file modificati non avevano senso per me, li ho solo nascosti e l’errore era sparito.

git:(master) git stash

commetti le tue modifiche (se ce ne sono) e poi git reset --hard

se hai un backup OLD e hai fretta:

crea un NUOVO BACKUP del tuo percorso di progetto corrente, rotto da git.

  1. sposta il tuo .git nel cestino (non eliminare mai)
  2. copia .git dal backup OLD
  3. git pull (creerà conflitti di fusione)
  4. sposta tutte le tue fonti (tutto ciò che hai messo in git) nel cestino: ./src (non eliminare mai)
  5. Copia tutte le tue fonti (tutto ciò che inserisci in git) dal NUOVO BACKUP
  6. accetta tutte le “unite” a git gui , spingi e … batti le mani!

La soluzione a 12 passaggi sopra descritta mi ha aiutato a tirarmi fuori da un ingorgo. Grazie. I passaggi chiave dovevano entrare:

 git fsck --full 

e rimuovi tutti gli oggetti vuoti

 rm .git/objects/... 

Quindi prendi le due linee del flog:

 tail -n 2 .git/logs/refs/heads/master 

Con i valori restituiti

 git update-ref HEAD ... 

A questo punto non ho più avuto errori, quindi ho fatto un backup dei miei file più recenti. Quindi fai un tiro di git seguito da un git push. Ho copiato i miei backup nel mio file git repository e ho fatto un altro push git. Questo mi ha fatto diventare attuale.

I miei colleghi e io ci siamo incrociati più volte con questo stesso problema e per risolverlo semplicemente facciamo i passi che descriverò qui sotto. Non è la soluzione più elegante che può essere trovata, ma funziona senza perdita di dati.

  1. Rinominare la directory di lavoro corrente. ( old_project per questo esempio).
  2. Clona il repository in una nuova directory usando git clone .
  3. Sulla riga di comando, cambia la directory di lavoro nel progetto appena creato e passa al ramo su cui hai lavorato.
  4. Copia tutti i file e le directory all’interno di old_project (eccetto la directory .git ) nella directory del progetto appena creata.
  5. Controlla lo stato del tuo albero di lavoro (nota che ci sono molte più modifiche di quanto ti aspetti) e poi commetti le modifiche.

Spero possa essere d’aiuto…

Ecco un modo per risolvere il problema se il repository pubblico su github.com funziona, ma il repository locale è danneggiato. Siate consapevoli che perderete tutti i commit che avete fatto nel repository locale.

Bene, quindi ho un repository locale che mi sta dando questo object empty error e lo stesso repository su github.com, ma senza questo errore. Quindi quello che ho fatto semplicemente è stato quello di clonare il repository che sta lavorando da github, e quindi copiare tutto dal repository corrotto (eccetto la cartella .git), e incollarlo sul repository clonato che sta funzionando.

Questa potrebbe non essere una soluzione pratica (poiché si eliminano i commit locali), tuttavia, si mantiene il codice e il controllo della versione riparata.

Ricordarsi di eseguire il backup prima di applicare questo approccio.

 git stash git checkout master cd .git/ && find . -type f -empty -delete git branch your-branch-name -D git checkout -b your-branch-name git stash pop 

risolvi il mio problema

Se non ti interessa mantenere i tuoi impegni storici, corri

rm -r .git

Quindi rispondere sì a tutto ciò che richiede l’eliminazione di file protetti da scrittura. Problema risolto in meno di un minuto.