Come correggere l'errore GIT: il file oggetto è vuoto?

Quando provo a eseguire il commit delle modifiche, visualizzo 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 fsckche 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 laptop ha esaurito la batteria durante un'operazione git. Boo.

Non avevo alcun backup. (NB Ubuntu One non è una soluzione di backup per git; sovrascriverà utile il tuo repository sano con quello corrotto.)

Ai maghi git, se questo è stato un brutto modo di risolverlo, per favore lascia un commento. Tuttavia, ha funzionato per me ... almeno temporaneamente.

Passaggio 1: esegui un backup di .git (in effetti 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

nathanvan@nathanvan-N61Jq:~/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 che diamine; è comunque vuoto.

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

Passaggio 3: eseguire git fscknuovamente. Continua a eliminare i file vuoti. Puoi anche cdaccedere alla .gitdirectory ed eseguire find . -type f -empty -delete -printper rimuovere tutti i file vuoti. Alla fine git ha iniziato a dirmi che stava effettivamente facendo qualcosa con le directory degli oggetti:

nathanvan@nathanvan-N61Jq:~/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 eliminato tutti i file vuoti, alla fine sono arrivato a git fsckcorrere effettivamente:

nathanvan@nathanvan-N61Jq:~/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: provare git reflog. Fallito perché la mia TESTA è rotta.

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git reflog
fatal: bad object HEAD

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

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ tail -n 2 .git/logs/refs/heads/master
f2d4c4868ec7719317a8fce9dc18c4f2e00ede04 9f0abf890b113a287e10d56b66dbab66adc1662d Nathan VanHoudnos <nathanvan@gmail.com> 1347306977 -0400  commit: up to p. 24, including correcting spelling of my name
9f0abf890b113a287e10d56b66dbab66adc1662d af9fc0c5939eee40f6be2ed66381d74ec2be895f Nathan VanHoudnos <nathanvan@gmail.com> 1347358589 -0400  commit: fixed up to page 28

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

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git show 9f0abf890b113a287e10d56b66dbab66adc1662d
commit 9f0abf890b113a287e10d56b66dbab66adc1662d
Author: Nathan VanHoudnos <nathanvan@XXXXXX>
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!

Step 8: Quindi ora dobbiamo puntare HEAD su 9f0abf890b113a287e10d56b66dbab66adc1662d.

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git update-ref HEAD 9f0abf890b113a287e10d56b66dbab66adc1662d

Che non si è lamentato.

Passaggio 9: vedi cosa dice fsck:

nathanvan@nathanvan-N61Jq:~/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

Passaggio 10: il puntatore sha1 non valido nell'albero della cache sembrava provenire da un file indice (ora obsoleto) ( origine ). Quindi l'ho ucciso e ripristinato il repository.

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ rm .git/index
nathanvan@nathanvan-N61Jq:~/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

Passaggio 11: guardare di nuovo fsck ...

nathanvan@nathanvan-N61Jq:~/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

Le chiazze penzolanti non sono errori . Non mi occupo di master.u1conflict, e ora che funziona non voglio più toccarlo!

Passaggio 12: recupero con le mie modifiche locali:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." 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")


nathanvan@nathanvan-N61Jq:~/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(-)

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git add tex/sept2012_code/example-code-testing.R
nathanvan@nathanvan-N61Jq:~/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 speriamo che possa essere di qualche utilità per le persone in futuro. Sono contento che abbia funzionato.

I file degli oggetti git sono diventati corrotti (come sottolineato anche in altre risposte). Ciò può accadere in caso di crash della macchina, ecc.

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

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

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

Ciò rimuoverà prima tutti i file di oggetti vuoti che causano il danneggiamento del repository nel suo insieme, quindi recupererà gli oggetti mancanti (nonché le ultime modifiche) dal repository remoto, quindi eseguirà un controllo completo dell'archivio oggetti . Che, a questo punto, dovrebbe avere successo senza errori (ci possono essere comunque alcuni avvertimenti!)

PS. Questa risposta suggerisce che hai una copia remota del tuo repository git da qualche parte (ad esempio su GitHub) e il repository rotto è il repository locale che è legato al repository remoto che è ancora intatto. In caso contrario, non tentare di risolverlo nel modo che raccomando.

Questo errore mi accade quando sto spingendo il mio commit e il mio computer si blocca. Ecco come l'ho risolto.

I passaggi per risolvere

git status

mostra il file oggetto vuoto / danneggiato

rm .git/objects/08/3834cb34d155e67a8930604d57d3d302d7ec12

rimuoverlo

git status

Ho ricevuto un fatal: bad object HEADmessaggio

rm .git/index

Rimuovo il indexper il reset

git reset

fatale: impossibile analizzare l'oggetto "HEAD".

git status
git pull

solo per controllare cosa sta succedendo

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

stampa le ultime 2 righe tail -n 2del ramo del registro per mostrare le mie ultime 2commit hash

git update-ref HEAD 7221fa02cb627470db163826da4265609aba47b2

Scelgo l'ultimo commit hash

git status

mostra tutto il mio file come deletedperché ho rimosso il .git/indexfile

git reset

continua il ripristino

git status

verifica la mia correzione

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

Ho risolto rimuovendo i vari file vuoti rilevati da git fsck e quindi eseguendo un semplice git pull.

Trovo deludente il fatto che ora che persino i filesystem implementano il journaling e altre tecniche "transazionali" per mantenere sano il fs, git può arrivare a uno stato corrotto (e non essere in grado di recuperare da solo) a causa di un'interruzione di corrente o spazio sul dispositivo.

Ho appena avuto lo stesso problema: dopo aver estratto il repository distante, quando ho fatto uno stato git ho ottenuto: "errore: il file oggetto (...) è vuoto" "fatale: l'oggetto sciolto (...) è danneggiato"

Il modo in cui l'ho risolto era:

1. git stash
2. rimuovere il file git per errore (non sono sicuro che sia necessario)
3. git stash chiaro

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 posso ripetere il processo descritto da @ Nathan-Vanhoudnos ogni volta che succede, anche se funziona 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

Clonare nuovamente il repository dall'origine.

git clone source_to_current_repo.git

Passaggio 3

Rimuovi tutto dal nuovo repository tranne la cartella .git .

Passaggio 4

Spostare tutto dal temp_repo al nuovo pronti contro termine , tranne il .git cartella .

Passaggio 5

Rimuovi temp_repo e abbiamo finito.

Dopo alcune volte, sono sicuro che puoi eseguire queste procedure molto rapidamente.

1. mv la tua app cartella per fare il backup, ad esempio mv app_folder app_folder_bk (è come una git stash )
2. git clone your_repository
3. Finalmente,. Apri uno strumento di unione (utilizzo meld diff viewer linux o Winmerge Windows) e copia le modifiche da destra ( app_folder_bk ) a sinistra (nuova app_folder ) (è come applicare un git stash ).

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

Nel mio caso, questo errore si è verificato perché stavo digitando il messaggio di commit e il mio notebook era 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 bene. Nel mio caso, ho dovuto eseguire il backup di 4 commit nella testa, ovvero fino a quando la mia testa non si trovava nel punto prima di digitare il messaggio di commit. Prima di fare questo passaggio, copia l'hash delle commit che ripristinerai, nel mio caso ho copiato l'hash delle 4 ultime commit
• git cherry-pick <commit-hash> # 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 # Spingi il nuovo ramo per essere sicuro che tutto funzioni bene
• git branch -D your-branch # Elimina il ramo localmente ('tuo-ramo' è il ramo con problema)
• git push origin :your-branch # Elimina il ramo dal telecomando
• git branch -m backup-branch your-branch # Rinominare il ramo di backup in modo che abbia il nome del ramo che presentava il problema
• git push origin your-branch # Spingi il nuovo ramo
• git push origin :backup-branch # Elimina il ramo di backup dal remoto

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

Ecco un modo davvero semplice e veloce per affrontare questo problema SE hai un repository locale con tutte le filiali e le commit di cui hai bisogno e se sei a posto con la creazione di un nuovo repository (o l'eliminazione del repository del server e la creazione di 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. Modificare l'URL remoto della copia locale in modo che punti all'URL remoto del nuovo repository.
3. Invia tutti i rami dal tuo repository locale al nuovo repository server.

Ciò preserva tutta la cronologia e le filiali di commit che hai avuto nel tuo repository locale.

Se hai dei collaboratori sul repository, penso che in molti casi tutto ciò che i tuoi collaboratori devono fare sia cambiare anche l'URL remoto del loro repository locale e, facoltativamente, eseguire il push di tutti i commit che il server non ha.

Questa soluzione ha funzionato per me quando ho riscontrato questo stesso problema. Ho avuto un collaboratore. Dopo aver inviato il repository locale al nuovo repository remoto, ha semplicemente cambiato il repository locale in modo che punti all'URL del repository remoto e tutto ha funzionato correttamente.

Suppongo che tu abbia un telecomando con tutte le modifiche rilevanti già inviate ad esso. Non mi importava delle modifiche locali e volevo semplicemente evitare di cancellare e ri-archiviare un repository di grandi dimensioni. Se hai importanti cambiamenti locali, potresti voler stare più attento.

Ho avuto lo stesso problema dopo il crash del mio laptop. Probabilmente perché era un grande repository avevo parecchi file di oggetti corrotti, che apparivano solo uno alla volta durante la chiamata git fsck --full, quindi ho scritto una piccola shell one-liner per eliminarne automaticamente uno:

$ 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 su stdout per poterlo grep
• opzioni grep utilizzate:
  • -o restituisce solo la parte di una riga che corrisponde effettivamente
  • -E abilita regex avanzati
  • -m 1 assicurarsi che venga restituita solo la prima corrispondenza
  • [0-9a-f]{2} corrisponde a uno qualsiasi dei caratteri tra 0 e 9 e a e f se due di essi si presentano insieme
  • [0-9a-f]* corrisponde a qualsiasi numero di caratteri compreso tra 0 e 9 e a e f che si verificano insieme

Elimina ancora solo un file alla volta, quindi potresti volerlo chiamare 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 genera più nulla di utile, quindi non sai quando è finito (non dovrebbe fare nulla di utile dopo un po 'di tempo)

Per "risolvere" questo, ho aggiunto una chiamata git fsck --fulldopo 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

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

Dopo questo ho giocato con alcuni dei suggerimenti di questo thread e finalmente sono arrivato al punto in cui ho potuto git stashe git stash dropmolte cose rotte.

primo problema risolto

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

$ git fetch

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

$ git remote prune origin

per buona misura e

git reflog expire --stale-fix --all

per sbarazzarsi di error: HEAD: invalid reflog entry $blubbquando si corre git fsck --full.

Andiamo semplice ... solo nel caso in cui hai caricato il sorgente sul repository git remoto

1. Fai il backup del tuo .git

2. controlla il tuo ingegno

   git fsck --full
   

3. rimuovere il file oggetto vuoto (tutti)

   rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e
   

4. controlla di nuovo il tuo git.

   git fsck --full
   

5. estrarre la fonte da git remoto

   git pull origin master
   

Ho riscontrato questo problema molto con le macchine virtuali.

Per me i seguenti lavori:

cd /path/to/your/project
rm -rf .git

Se vuoi salvarti alcuni download - vai nel tuo esploratore di file ed elimina tutti i file nella cartella che sono già impegnati e lasciati nelle tue cartelle / vendor e / node_modules (lavoro con compositore e npm).

quindi basta creare un nuovo repository

git init

aggiungi il tuo telecomando

git remote add origin ssh://git@github.com/YourUsername/repoName.git

e recupera il ramo / tutto

git fetch origin somebranch

e dai un'occhiata

git checkout somebranch

allora dovresti essere al punto prima dell'errore.

Spero che sia di aiuto.

Saluti.

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

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

Io e i miei colleghi abbiamo attraversato più volte lo stesso problema e per risolverlo facciamo semplicemente i passaggi che descrivo di seguito. Non è la soluzione più elegante che si possa trovare ma funziona senza perdita di dati.

1. Rinomina la directory di lavoro corrente. (old_project per questo esempio).
2. Clonare il repository in una nuova directory utilizzando git clone.
3. Sulla riga di comando, cambia la directory di lavoro nel progetto appena creato e passa al ramo su cui stai lavorando.
4. Copia tutti i file e le directory all'interno old_project(tranne la .gitdirectory) nella directory del progetto appena creata.
5. Controlla lo stato dell'albero di lavoro (tieni presente che ci sono molte più modifiche di quanto ti aspetti) e quindi esegui il commit delle modifiche.

Spero possa essere d'aiuto...

Ecco un modo per risolvere il problema se il tuo repository pubblico su github.com funziona, ma il tuo repository locale è corrotto. Tieni presente che perderai tutti i commit che hai 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 semplicemente fatto è stato clonare il repository che sta funzionando da Github, quindi copiare tutto dal repository corrotto (tranne la cartella .git) e incollarlo nel repository clonato che sta funzionando.

Questa potrebbe non essere una soluzione pratica (poiché elimini i commit locali), tuttavia mantieni il codice e un controllo di versione riparato.

Ricorda di eseguire il backup prima di applicare questo approccio.

Nel mio caso, non è stato importante per me mantenere la cronologia degli commit locali. Quindi, se questo vale anche per te, puoi farlo come una rapida alternativa alle soluzioni sopra:

In pratica, sostituisci semplicemente la .git/directory danneggiata con una nuova.

Presumiamo la seguente directory per il tuo progetto con git corrotto: projects/corrupt_git/

1. cp projects/corrupt_git projects/backup - (facoltativo) eseguire un backup
2. git clone [repo URL] projects/clean_git - in modo da ottenere projects/clean_git
3. rm -rf corrupt_git/.git/ - rimuovere la cartella .git danneggiata
4. mv clean_git/.git/ corrupt_git/ - sposta git pulito su corrupt_git/.git
5. git statusin projects/corrupt_git- per assicurarsi che funzionasse

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

git remote -v
 origin git@github.com:rwldrn/idiomatic.js.git (fetch)
 origin git@github.com:rwldrn/idiomatic.js.git (push)

Poi

mkdir mygitfolder.backup
cp mygitfolder/* mygitfolder.backup/
cd mygitfolder
rm -r * .git*
git init
git remote add origin git@github.com:rwldrn/idiomatic.js.git

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

Ha avuto lo stesso problema dopo aver verificato il master da un ramo pulito. Dopo un po 'ho riconosciuto molti file modificati in master. Non so perché siano stati lì, dopo essere passati da un ramo pulito. Comunque, poiché i file modificati non avevano alcun senso per me, li ho semplicemente nascosti e l'errore era sparito.

git:(master) git stash

se hai un backup VECCHIO ed hai fretta:

crea un NUOVO BACKUP del tuo percorso di progetto attuale, git-broken.

1. sposta il tuo .gitcestino (non eliminare mai)
2. copia .gitdal backup OLD
3. git pull (creerà conflitti di unione)
4. sposta tutte le tue fonti (tutto ciò che hai inserito in git) nel cestino: ./src (non eliminare mai)
5. .copia tutte le tue fonti (tutto ciò che hai inserito in git) dal NUOVO BACKUP
6. accetta tutte le "fusioni" a git gui, spingi e ... batti le mani!

La soluzione in dodici passaggi descritta sopra mi ha aiutato anche a farmi fuori da un ingorgo. Grazie. I passaggi chiave sono stati inserire:

git fsck --full 

e rimuovi tutti gli oggetti vuoti

rm .git/objects/...

Quindi ottenere 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 avuto più errori, quindi ho fatto un backup dei miei file più recenti. Quindi esegui un pull git seguito da un push git. Ho copiato i miei backup nel mio file repository git e ho fatto un altro git push. Mi ha fatto conoscere.

Ho corretto il mio errore git: il file oggetto è vuoto da:

1. Salvataggio di una copia di tutti i file che ho modificato dal mio ultimo commit / push,
2. Rimozione e nuova clonazione del mio repository,
3. Sostituzione dei vecchi file con i miei file modificati.

Spero che questo aiuti.

Questo succede anche a me quasi regolarmente. Non ho creato un protocollo quando questo accade esattamente, ma ho il sospetto che si verifichi ogni volta che la mia macchina virtuale esiste "inaspettatamente". Se chiudo la finestra della VM (sto usando Ubuntu 18.04) e ricomincio, le cose funzionano sempre (?). Ma se la finestra della VM è ancora aperta quando il mio laptop è spento (sistema host Windows), allora riscontro questo problema piuttosto frequentemente.

Per quanto riguarda tutte le risposte fornite qui:

1. grazie - sono molto utili; Di solito, salvo una copia locale del mio codice, ripristino il repository da remoto e sposto la copia di backup nella cartella locale.

2. poiché il problema di fondo non è in realtà un problema git, ma piuttosto un problema di VM e / o Linux, mi chiedo se non ci dovrebbe essere un modo per curare la ragione piuttosto i sintomi? Questo tipo di errore non indica che alcune modifiche al file system non vengono "applicate" in un tempo ragionevole, ma solo memorizzate nella cache? (vedi ad esempio /unix/464184/are-file-edits-in-linux-directly-saved-into-disk ) - a me sembra che le macchine virtuali Linux non lo facciano sincronizza le loro cose abbastanza frequentemente. Che si tratti di un problema del VirtualBox di Oracle (che altrimenti funziona molto bene) o del file system guest, o di alcune impostazioni, che tutti noi trascuriamo, è al di là delle mie competenze. Ma sarei felice se qualcuno potesse far luce su questo.

In realtà ho avuto lo stesso problema. Prendi una copia del tuo codice prima di provare questo.

L'ho appena fatto git reset HEAD~

il mio ultimo commit è stato annullato, quindi l'ho commesso di nuovo, problema risolto!

Avvertimento: con più esperienza, mi rendo conto che questa è l'opzione nucleare e in genere non dovrebbe essere fatta e non insegna nulla. Tuttavia, in rare occasioni per progetti personali, l'ho ancora trovato utile, quindi lo lascio perdere.

Se non ti interessa mantenere i tuoi impegni storici, corri e basta

rm -r .git

Quindi rispondere di sì a qualsiasi domanda sull'eliminazione di file protetti da scrittura. Problema risolto in meno di un minuto.