Ogni volta che estraggo dal telecomando, viene visualizzato il seguente errore relativo alla compressione. Quando eseguo la compressione manuale, ottengo lo stesso:

$ git gc
error: Could not read 3813783126d41a3200b35b6681357c213352ab31
fatal: bad tree object 3813783126d41a3200b35b6681357c213352ab31
error: failed to run repack

Qualcuno sa cosa fare al riguardo?

Da cat-file ottengo questo:

$ git cat-file -t 3813783126d41a3200b35b6681357c213352ab31
error: unable to find 3813783126d41a3200b35b6681357c213352ab31
fatal: git cat-file 3813783126d41a3200b35b6681357c213352ab31: bad file

E da git fsck ottengo questo (non so se è effettivamente correlato):

$ git fsck
error: inflate: data stream error (invalid distance too far back)
error: corrupt loose object '45ba4ceb93bc812ef20a6630bb27e9e0b33a012a'
fatal: loose object 45ba4ceb93bc812ef20a6630bb27e9e0b33a012a (stored in .git/objects/45/ba4ceb93bc812ef20a6630bb27e9e0b33a012a) is corrupted

Qualcuno può aiutarmi a decifrare questo?

Sembra che tu abbia un oggetto albero corrotto. Dovrai ottenere quell'oggetto da qualcun altro. Speriamo che abbiano una versione non corrotta.

Potresti effettivamente ricostruirlo se non riesci a trovare una versione valida da qualcun altro indovinando quali file dovrebbero essere lì. Potresti voler vedere se le date e gli orari degli oggetti corrispondono. Quelli potrebbero essere i BLOB correlati. È possibile dedurre la struttura dell'oggetto albero da tali oggetti.

Dai un'occhiata ai Git Screencast di Scott Chacon per quanto riguarda gli interni git. Questo ti mostrerà come funziona git sotto il cofano e come fare per fare questo lavoro investigativo se sei davvero bloccato e non riesci a ottenere quell'oggetto da qualcun altro.

Ho avuto lo stesso problema (non so perché).

Questa correzione richiede l'accesso a una copia remota non corrotta del repository e manterrà intatta la copia di lavoro locale.

Ma ha alcuni inconvenienti:

• Perderai il record di tutti i commit che non sono stati inviati e dovrai riconsiderarli.
• Perderai eventuali scorie.

La correzione

Esegui questi comandi dalla directory principale sopra il tuo repository (sostituisci "pippo" con il nome della cartella del tuo progetto):

1. Creare un backup della directory corrotta:
   cp -R foo foo-backup
2. Crea un nuovo clone del repository remoto in una nuova directory:
   git clone git@www.mydomain.de:foo foo-newclone
3. Elimina la sottodirectory .git corrotta:
   rm -rf foo/.git
4. Sposta la sottodirectory .git appena clonata in foo:
   mv foo-newclone/.git foo
5. Elimina il resto del nuovo clone temporaneo:
   rm -rf foo-newclone

Su Windows dovrai usare:

• copy invece di cp -R
• rmdir /S invece di rm -rf
• move invece di mv

Ora foo ha la sua .gitsottodirectory originale , ma tutte le modifiche locali sono ancora lì. git status, commit, pull, push, Ecc lavorare di nuovo come dovrebbero.

La tua scommessa migliore è probabilmente quella di ri-clonare dal repository remoto (es. Github o altro). Sfortunatamente perderai tutti i commit non compressi e le modifiche nascoste, tuttavia la tua copia di lavoro dovrebbe rimanere intatta.

Prima fai una copia di backup dei tuoi file locali. Quindi fai questo dalla radice del tuo albero di lavoro:

rm -fr .git
git init
git remote add origin [your-git-remote-url]
git fetch
git reset --mixed origin/master
git branch --set-upstream-to=origin/master master  

Quindi eseguire il commit di tutti i file modificati, se necessario.

Lavorando su una VM, sul mio notebook, la batteria si è esaurita, ho riscontrato questo errore;

errore: il file oggetto .git / objects / ce / theRef è vuoto errore: il file oggetto .git / objects / ce / theRef è vuoto fatale: oggetto sciolto theRef (memorizzato in .git / objects / ce / theRef) è danneggiato

Sono riuscito a far funzionare nuovamente il repository con solo 2 comandi e senza perdere il mio lavoro (file modificati / modifiche non confermate)

find .git/objects/ -size 0 -exec rm -f {} \;
git fetch origin

Dopo di che ho eseguito un git status, il repository andava bene e c'erano i miei cambiamenti (in attesa di essere impegnati, fallo ora ..).

versione git 1.9.1

Ricorda di eseguire il backup di tutte le modifiche che ricordi, nel caso in cui questa soluzione non funzioni e sia necessario un approccio più radicale.

Il mio computer si è bloccato durante la scrittura di un messaggio di commit. Dopo il riavvio, l'albero di lavoro era come l'avevo lasciato e sono stato in grado di eseguire correttamente il commit delle mie modifiche.

Tuttavia, quando ho provato a correre git statusho ottenuto

error: object file .git/objects/xx/12345 is empty
fatal: loose object xx12345 (stored in .git/objects/xx/12345 is corrupt

A differenza della maggior parte delle altre risposte, non stavo cercando di recuperare alcun dato . Avevo solo bisogno di Git per smettere di lamentarmi del file oggetto vuoto.

Panoramica

Il "file oggetto" è la rappresentazione hash di git di un file reale che ti interessa. Git pensa che dovrebbe avere una versione hash di some/file.whatevermemorizzata in .git/object/xx/12345, e fissare l'errore si è rivelata soprattutto una questione di capire quale file "oggetto loose" avrebbe dovuto rappresentare.

Dettagli

Le possibili opzioni sembravano esserlo

1. Elimina il file vuoto
2. Porta il file in uno stato accettabile per Git

Approccio 1: rimuovere il file oggetto

La prima cosa che ho provato è stato semplicemente spostare il file oggetto

mv .git/objects/xx/12345 ..

Non ha funzionato - Git ha iniziato a lamentarsi di un collegamento interrotto. All'approccio 2.

Approccio 2: correggere il file

Linus Torvalds ha un ottimo resoconto su come recuperare un file oggetto che ha risolto il problema per me. I passaggi chiave sono riepilogati qui.

$> # Find out which file the blob object refers to
$> git fsck
broken link from    tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
           to    blob xx12345
missing blob xx12345

$> git ls-tree 2d926
...
10064 blob xx12345  your_file.whatever

Questo ti dice di quale file l'oggetto vuoto dovrebbe essere un hash. Ora puoi ripararlo.

$> git hash-object -w path/to/your_file.whatever

Dopo aver fatto questo ho controllato .git/objects/xx/12345, non era più vuoto e git ha smesso di lamentarsi.

Provare

git stash

Questo ha funzionato per me. Blocca tutto ciò che non hai commesso e che ha aggirato il problema.

Una garbage collection ha risolto il mio problema:

git gc --aggressive --prune=now

Ci vuole un po 'per completare, ma ogni oggetto sciolto e / o indice corrotto è stato corretto.

semplicemente eseguendo un git pruneproblema risolto per me

L'ho appena sperimentato: la mia macchina si è arrestata in modo anomalo durante la scrittura nel repository Git e si è danneggiata. L'ho risolto come segue.

Ho iniziato osservando quanti commit non avevo spinto nel repository remoto, quindi:

gitk &

Se non si utilizza questo strumento, è molto utile, disponibile su tutti i sistemi operativi per quanto ne so. Ciò indicava che nel mio telecomando mancavano due commit. Ho quindi cliccato sull'etichetta indicando l'ultimo commit remoto (di solito questo sarà /remotes/origin/master) per ottenere l'hash (l'hash è lungo 40 caratteri, ma per brevità sto usando 10 qui - di solito funziona comunque).

Ecco qui:

14c0fcc9b3

Quindi faccio clic sul seguente commit (ovvero il primo che il telecomando non ha) e ottengo l'hash lì:

04d44c3298

Quindi uso entrambi per creare una patch per questo commit:

git diff 14c0fcc9b3 04d44c3298 > 1.patch

Ho quindi fatto lo stesso con l'altro commit mancante, cioè ho usato l'hash del commit prima e l'hash del commit stesso:

git diff 04d44c3298 fc1d4b0df7 > 2.patch

Mi sono quindi spostato in una nuova directory, clonato il repository dal telecomando:

git clone git@github.com:username/repo.git

Ho quindi spostato i file patch nella nuova cartella, li ho applicati e li ho impegnati con i loro messaggi di commit esatti (questi possono essere incollati dalla git logo dalla gitkfinestra):

patch -p1 < 1.patch
git commit

patch -p1 < 2.patch
git commit

Ciò ha ripristinato le cose per me (e nota che probabilmente c'è un modo più veloce per farlo per un gran numero di commit). Tuttavia, volevo vedere se l'albero nel repository corrotto può essere riparato e la risposta è che può. Con un repository riparato disponibile come sopra, esegui questo comando nella cartella danneggiata:

git fsck 

Otterrai qualcosa del genere:

error: object file .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d is empty
error: unable to find ca539ed815fefdbbbfae6e8d0c0b3dbbe093390d
error: sha1 mismatch ca539ed815fefdbbbfae6e8d0c0b3dbbe093390d

Per fare la riparazione, lo farei nella cartella rotta:

rm .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d
cp ../good-repo/.git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d

cioè rimuovere il file danneggiato e sostituirlo con uno buono. Potrebbe essere necessario farlo più volte. Finalmente ci sarà un punto in cui è possibile eseguire fscksenza errori. Probabilmente avrai delle righe "commit in sospensione" e "blob in sospensione" nel rapporto, queste sono una conseguenza delle tue modifiche e modifiche in questa cartella e sono OK. Il garbage collector li rimuoverà a tempo debito.

Quindi (almeno nel mio caso) un albero corrotto non significa che i commit non compressi vengano persi.

Stavo ottenendo anche un errore di oggetto sciolto danneggiato.

./objects/x/x

Ho risolto con successo andando nella directory dell'oggetto corrotto. Ho visto che gli utenti assegnati a quell'oggetto non erano i miei utenti git. Non so come sia successo, ma ho eseguito un chown git:gitfile su quel file e poi ha funzionato di nuovo.

Questa potrebbe essere una possibile soluzione per i problemi di alcune persone, ma non è necessaria per tutte.

Ho ricevuto questo errore dopo che la mia macchina (windows) ha deciso di riavviarsi. Per fortuna il mio repository remoto era aggiornato, quindi ho appena fatto un nuovo clone git ..

Runnning ha git stash; git stash poprisolto il mio problema

Ho seguito molti degli altri passaggi qui; La descrizione di Linus su come guardare l'albero git / gli oggetti e scoprire cosa manca è stata particolarmente utile. git-git recupera BLOB corrotto

Ma alla fine, per me, ho avuto oggetti albero sciolti / corrotti causati da un parziale guasto del disco e gli oggetti albero non sono così facilmente recuperati / non coperti da quel documento.

Alla fine, ho spostato il conflitto objects/<ha>/<hash>fuori mano, e usato git unpack-objectscon un file pack da un clone ragionevolmente aggiornato. È stato in grado di ripristinare gli oggetti dell'albero mancanti.

Mi ha ancora lasciato un sacco di macchie penzolanti, che possono essere un effetto collaterale del disimballaggio di oggetti precedentemente archiviati e affrontate in altre domande qui

In risposta a @ user1055643 manca l'ultimo passaggio:

$ rm -fr .git
$ git init
$ git remote add origin your-git-remote-url
$ git fetch
$ git reset --hard origin/master
$ git branch --set-upstream-to=origin/master master  

Abbiamo appena avuto il caso qui. È successo che il problema era che la proprietà del file corrotto era root anziché il nostro normale utente. Ciò è stato causato da un commit eseguito sul server dopo che qualcuno ha eseguito un "sudo su -".

Innanzitutto, identifica il tuo file corrotto con:

$> git fsck --full

Dovresti ricevere una risposta come questa:

fatal: loose object 11b25a9d10b4144711bf616590e171a76a35c1f9 (stored in .git/objects/11/b25a9d10b4144711bf616590e171a76a35c1f9) is corrupt

Vai nella cartella in cui si trova il file danneggiato e fai un:

$> ls -la

Controlla la proprietà del file corrotto. Se è diverso, torna alla radice del tuo repository e fai un:

$> sudo chown -R YOURCORRECTUSER:www-data .git/

Spero che sia d'aiuto!

A me questo è successo a causa di un'interruzione di corrente mentre si esegue un git push .

I messaggi sembravano così:

$ git status
error: object file .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74 is empty
error: object file .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74 is empty
fatal: loose object c238824eb3fb602edc2c49fccb535f9e53951c74 (stored in .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74) is corrupt

Ho provato cose del genere git fsckma questo non ha aiutato. Poiché l'arresto si è verificato durante un git push, è ovviamente accaduto durante la riscrittura sul lato client che si verifica dopo l'aggiornamento del server. Mi sono guardato intorno e ho pensato che c2388nel mio caso fosse un oggetto commit, perché era indicato da voci in .git/refs. Quindi sapevo che sarei stato in grado di trovarec2388 quando guardavo la storia (attraverso un'interfaccia web o un secondo clone).

Sul secondo clone ho fatto un git log -n 2 c2388per identificare il predecessore di c2388. Poi ho modificato manualmente .git/refs/heads/mastere .git/refs/remotes/origin/masterper essere il predecessore c2388invece di c2388. Quindi potrei fare un git fetch. Il git fetchfallito alcune volte per conflitti su oggetti vuoti. Ho rimosso ciascuno di questi oggetti vuoti fino git fetcha quando non ci sono riuscito. Ciò ha guarito il repository.

Ho risolto in questo modo: ho deciso di copiare semplicemente il file oggetto non corrotto dal clone del backup nel mio repository originale. Questo ha funzionato altrettanto bene. (A proposito: se non riesci a trovare l'oggetto in .git / objects / con il suo nome, probabilmente è stato [impacchettato] [pacchetto] per risparmiare spazio.)

Ho avuto lo stesso problema nel mio repository git remoto remoto. Dopo aver risolto molti problemi, ho scoperto che uno dei miei colleghi aveva fatto un commit in cui alcuni file in .git / objects avevano i permessi di 440 (r - r -----) invece di 444 (r - r - r -). Dopo aver chiesto al collega di modificare le autorizzazioni con "oggetti chmod 444 -R" all'interno del repository bare git, il problema è stato risolto.

Ho appena avuto un problema come questo. Il mio problema particolare è stato causato da un arresto anomalo del sistema che ha corrotto il commit più recente (e quindi anche il ramo principale). Non avevo spinto e volevo ripetere quell'impegno. Nel mio caso particolare, sono stato in grado di affrontarlo in questo modo:

1. Effettuare un backup di .git/ :rsync -a .git/ git-bak/
2. Controlla .git/logs/HEADe trova l'ultima riga con un ID commit valido. Per me, questo è stato il secondo impegno più recente. Questo andava bene, perché avevo ancora le versioni di directory di lavoro del file, e quindi ogni versione che volevo.
3. Crea un ramo a quel commit: git branch temp <commit-id>
4. ripetere il commit interrotto con i file nella directory di lavoro.
5. git reset master temp per spostare il ramo master sul nuovo commit effettuato nel passaggio 2.
6. git checkout master e controlla che vada bene con git log .
7. git branch -d temp.
8. git fsck --fulle ora dovrebbe essere sicuro eliminare tutti gli oggetti danneggiati che fsck trova.
9. Se tutto sembra a posto, prova a spingere. Se funziona,

Ha funzionato per me. Ho il sospetto che questo sia uno scenario ragionevolmente comune, poiché il commit più recente è il più probabile da corrompere, ma se ne perdi uno più indietro, probabilmente puoi ancora utilizzare un metodo come questo, con un uso attento git cherrypicke il reflog in .git/logs/HEAD.

Quando ho riscontrato questo problema, ho eseguito il backup delle mie ultime modifiche (poiché sapevo cosa avevo modificato), quindi ho eliminato il file di cui si lamentava in .git / location. Poi ho fatto una git pull. Attenzione però, questo potrebbe non funzionare per te.

L'ho riscontrato una volta che il mio sistema si è bloccato. Quello che ho fatto è questo:

(Si noti che i commit danneggiati vengono persi, ma le modifiche vengono mantenute. Potrebbe essere necessario ricreare tali commit al termine di questa procedura)

• Fai il backup del tuo codice.
• Vai alla tua directory di lavoro ed elimina la .gitcartella.
• Ora clona il telecomando in un'altra posizione e copia la .gitcartella in esso.
• Incollalo nella tua directory di lavoro.
• Impegnati come volevi.

Rimuovi la cartella .git e aggiungila di nuovo. Questa semplice soluzione ha funzionato per me.