Comment corriger l'erreur GIT: le fichier objet est vide?

Lorsque j'essaie de valider les modifications, j'obtiens cette erreur:

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

Une idée comment résoudre cette erreur?

ÉDITER

J'ai essayé git fsckj'ai:

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

J'avais un problème similaire. Mon ordinateur portable a manqué de batterie pendant une opération git. Huer.

Je n'ai eu aucune sauvegarde. (NB Ubuntu One n'est pas une solution de sauvegarde pour git; il écrasera utilement votre référentiel sain avec celui corrompu.)

Aux assistants git, si c'était une mauvaise façon de le réparer, veuillez laisser un commentaire. Cela a cependant fonctionné pour moi ... au moins temporairement.

Étape 1: Faites une sauvegarde de .git (en fait, je le fais entre chaque étape qui change quelque chose, mais avec un nouveau nom de copie, par exemple .git-old-1, .git-old-2, etc.) :

cp -a .git .git-old

Étape 2: exécuter 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

Étape 3: supprimez le fichier vide. J'ai compris ce que diable; son blanc de toute façon.

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

Étape 3: exécutez à git fscknouveau. Continuez à supprimer les fichiers vides. Vous pouvez également cddans le .gitrépertoire et exécuter find . -type f -empty -delete -printpour supprimer tous les fichiers vides. Finalement, git a commencé à me dire qu'il faisait en fait quelque chose avec les répertoires d'objets:

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

Étape 4: Après avoir supprimé tous les fichiers vides, j'ai fini par git fsckexécuter:

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

Étape 5: essayez git reflog. Échec car ma tête est cassée.

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

Étape 6: Google. Trouvez ça . Obtenez manuellement les deux dernières lignes du 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

Étape 7: Notez qu'à partir de l'étape 6, nous avons appris que le HEAD pointe actuellement vers le tout dernier commit. Essayons donc de regarder le commit parent:

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

Ça a marché!

Étape 8: Nous devons maintenant pointer HEAD sur 9f0abf890b113a287e10d56b66dbab66adc1662d.

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

Qui ne s'est pas plaint.

Étape 9: voir ce que fsck dit:

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

Étape 10: Le pointeur sha1 non valide dans l'arborescence du cache semblait provenir d'un fichier d'index (désormais obsolète) ( source ). Je l'ai donc tué et réinitialisé le dépôt.

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

Étape 11: nouveau regard sur le 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

Les blobs pendants ne sont pas des erreurs . Je ne suis pas concerné par master.u1conflict, et maintenant qu'il fonctionne, je ne veux plus y toucher!

Étape 12: rattraper mes modifications locales:

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

J'espère donc que cela pourra être utile aux gens à l'avenir. Je suis content que ça ait marché.

Les fichiers objets git sont devenus corrompus (comme indiqué dans d'autres réponses également). Cela peut se produire lors de pannes de machines, etc.

J'avais la même chose. Après avoir lu les autres principales réponses ici, j'ai trouvé le moyen le plus rapide de corriger le référentiel git cassé avec les commandes suivantes (exécutez dans le répertoire de travail git qui contient le .gitdossier):

(Assurez-vous de sauvegarder d'abord votre dossier de référentiel git!)

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

Cela supprimera d' abord tous les fichiers d'objets vides qui provoquent la corruption du référentiel dans son ensemble, puis récupérera les objets manquants (ainsi que les dernières modifications) du référentiel distant, puis effectuera une vérification complète du magasin d'objets . Ce qui, à ce stade, devrait réussir sans erreur (il peut cependant y avoir quelques avertissements!)

PS. Cette réponse suggère que vous avez une copie distante de votre référentiel git quelque part (par exemple sur GitHub) et que le référentiel cassé est le référentiel local qui est lié au référentiel distant qui est toujours en contact. Si ce n'est pas le cas, n'essayez pas de le réparer comme je le recommande.

Cette erreur m'arrive lorsque je pousse mon commit et que mon ordinateur se bloque. Voilà comment je l'ai corrigé.

Étapes à suivre

git status

afficher le fichier objet vide / corrompu

rm .git/objects/08/3834cb34d155e67a8930604d57d3d302d7ec12

le retirer

git status

J'ai un fatal: bad object HEADmessage

rm .git/index

Je supprime le indexpour la réinitialisation

git reset

fatal: impossible d'analyser l'objet 'HEAD'.

git status
git pull

juste pour vérifier ce qui se passe

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

imprime les 2 dernières lignes tail -n 2de la branche du journal pour afficher mes 2 dernièrescommit hash

git update-ref HEAD 7221fa02cb627470db163826da4265609aba47b2

Je choisis le dernier commit hash

git status

montre tout mon fichier comme deletedparce que j'ai supprimé le .git/indexfichier

git reset

continuer la réinitialisation

git status

vérifier ma correction

Remarque: Les étapes commencent lorsque j'ai atterri sur cette question et utilisé les réponses comme référence.

J'ai résolu cela en supprimant les divers fichiers vides que git fsck détectait, puis en exécutant un simple pull git.

Je trouve décevant que maintenant que même les systèmes de fichiers implémentent la journalisation et d'autres techniques "transactionnelles" pour garder le fs sain d'esprit, git puisse atteindre un état corrompu (et ne pas être en mesure de récupérer par lui-même) en raison d'une panne de courant ou de l'espace sur l'appareil.

J'ai juste eu le même problème: après avoir tiré le référentiel distant, quand j'ai fait un état git, j'ai eu: "erreur: le fichier objet (...) est vide" "fatal: l'objet lâche (...) est corrompu"

La façon dont j'ai résolu cela était de:

1. git stash
2. suppression du fichier git par erreur (pas sûr que ce soit nécessaire)
3. git stash clear

Je ne sais pas exactement ce qui s'est passé, mais ces instructions semblaient tout nettoyer.

Parce que je dois redémarrer régulièrement ma machine virtuelle, donc ce problème m'arrive très souvent. Après quelques fois, j'ai réalisé que je ne pouvais pas répéter le processus décrit par @ Nathan-Vanhoudnos à chaque fois que cela se produisait, bien que cela fonctionne toujours. Ensuite, j'ai trouvé la solution plus rapide suivante.

Étape 1

Déplacez votre référentiel entier vers un autre dossier.

mv current_repo temp_repo

Étape 2

Clonez à nouveau le dépôt d'origine.

git clone source_to_current_repo.git

Étape 3

Supprimez tout sous le nouveau référentiel à l'exception du dossier .git .

Étape 4

Déplacez tout du temp_repo vers le nouveau dépôt sauf le dossier .git .

Étape 5

Supprimer le temp_repo , et nous avons terminé.

Après quelques fois, je suis sûr que vous pouvez effectuer ces procédures très rapidement.

1. mv votre application de dossier pour faire une sauvegarde, c.-à-d. mv app_folder app_folder_bk (c'est comme une cachette git )
2. git clone your_repository
3. Finalement,. Ouvrez un outil de fusion (j'utilise meld diff viewer linux ou Winmerge Windows) et copiez les modifications de droite ( app_folder_bk ) vers la gauche (new app_folder ) (c'est comme une application git stash ).

C'est tout. Ce n'est peut-être pas le meilleur moyen, mais je pense que c'est tellement pratique.

Dans mon cas, cette erreur s'est produite car je tapais le message de validation et mon bloc-notes s'est éteint.

J'ai fait ces étapes pour corriger l'erreur:

• git checkout -b backup-branch # Créer une branche de sauvegarde
• git reset --hard HEAD~4# Réinitialisez le commit où tout fonctionne bien. Dans mon cas, j'ai dû sauvegarder 4 validations dans la tête, c'est-à-dire jusqu'à ce que ma tête soit au point avant de taper le message de validation.Avant de faire cette étape, copiez le hachage des commits que vous allez réinitialiser, dans mon cas j'ai copié le hachage des 4 derniers commits
• git cherry-pick <commit-hash> # Cherry sélectionne les commits réinitialisés (dans mon cas, il y a 4 commits, j'ai donc fait cette étape 4 fois) de l'ancienne branche vers la nouvelle branche.
• git push origin backup-branch # Poussez la nouvelle branche pour être sûr que tout fonctionne bien
• git branch -D your-branch # Supprimez la branche localement ('votre-branche' est la branche à problème)
• git push origin :your-branch # Supprimer la branche de la télécommande
• git branch -m backup-branch your-branch # Renommez la branche de sauvegarde pour avoir le nom de la branche qui a rencontré le problème
• git push origin your-branch # Poussez la nouvelle branche
• git push origin :backup-branch # Supprimer la branche de sauvegarde de la télécommande

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

résoudre mon problème

Voici un moyen très simple et rapide de résoudre ce problème SI vous avez un référentiel local avec toutes les branches et les commits dont vous avez besoin, et si vous êtes d'accord pour créer un nouveau référentiel (ou supprimer le référentiel du serveur et en créer un nouveau) à sa place):

1. Créez un nouveau référentiel vide sur le serveur (ou supprimez l'ancien référentiel et créez-en un nouveau à sa place)
2. Modifiez l'URL distante de votre copie locale pour pointer vers l'URL distante du nouveau référentiel.
3. Transférez toutes les branches de votre référentiel local vers le nouveau référentiel de serveur.

Cela préserve tout l'historique des validations et les branches que vous aviez dans votre référentiel local.

Si vous avez des collaborateurs sur le référentiel, je pense que dans de nombreux cas, tous vos collaborateurs doivent également modifier l'URL distante de leur référentiel local, et éventuellement pousser tous les commits qu'ils ont que le serveur n'a pas.

Cette solution a fonctionné pour moi lorsque j'ai rencontré ce même problème. J'avais un collaborateur. Après avoir transféré mon référentiel local vers le nouveau référentiel distant, il a simplement changé son référentiel local pour pointer vers l'URL du référentiel distant et tout a bien fonctionné.

Je suppose que vous avez une télécommande avec tous les changements pertinents déjà poussés. Je ne me souciais pas des changements locaux et je voulais simplement éviter de supprimer et de recloner un grand référentiel. Si vous avez des changements locaux importants, vous voudrez peut-être être plus prudent.

J'ai eu le même problème après le crash de mon ordinateur portable. Probablement parce que c'était un grand référentiel, j'avais pas mal de fichiers objets corrompus, qui n'apparaissaient qu'un par un lors de l'appel git fsck --full, j'ai donc écrit un petit shell one-liner pour supprimer automatiquement l'un d'eux:

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

• 2>&1 redirige le message d'erreur vers stdout pour pouvoir le récupérer
• options grep utilisées:
  • -o renvoie uniquement la partie d'une ligne qui correspond réellement
  • -E permet des expressions rationnelles avancées
  • -m 1 assurez-vous que seule la première correspondance est renvoyée
  • [0-9a-f]{2} correspond à l'un des caractères compris entre 0 et 9 et a et f si deux d'entre eux se produisent ensemble
  • [0-9a-f]* correspond à n'importe quel nombre de caractères compris entre 0 et 9 et a et f apparaissant ensemble

Il ne supprime toujours qu'un fichier à la fois, vous pouvez donc l'appeler dans une boucle comme:

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

Le problème avec cela est qu'il ne produit plus rien d'utile, donc vous ne savez pas quand il est terminé (il ne devrait tout simplement pas faire quoi que ce soit d'utile après un certain temps)

Pour "corriger" cela, j'ai simplement ajouté un appel git fsck --fullaprès chaque tour comme ceci: $ 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

Il est maintenant environ deux fois moins rapide, mais il affiche son "état".

Après cela, j'ai joué avec les suggestions de ce fil et j'ai finalement atteint un point où je pouvais git stashet git stash dropbeaucoup de choses cassées.

premier problème résolu

Par la suite, j'ai toujours eu le problème suivant: unable to resolve reference 'refs/remotes/origin/$branch': reference brokenqui pourrait être résolu par $ rm \repo.git\refs\remotes\origin\$branch

$ git fetch

J'ai ensuite fait un $ git gc --prune=now

$ git remote prune origin

pour faire bonne mesure et

git reflog expire --stale-fix --all

se débarrasser de la error: HEAD: invalid reflog entry $blubbcourse git fsck --full.

Allons simple .. seulement si vous avez téléchargé la source sur le dépôt git distant

1. Sauvegardez votre .git

2. vérifiez votre git

   git fsck --full
   

3. supprimer le fichier objet vide (tout)

   rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e
   

4. vérifiez à nouveau votre git.

   git fsck --full
   

5. tirez votre source de git distant

   git pull origin master
   

Je rencontre beaucoup ce problème avec les machines virtuelles.

Pour moi les oeuvres suivantes:

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

Si vous voulez vous sauver quelques téléchargements - allez dans votre explorateur de fichiers et supprimez tous les fichiers dans le dossier qui sont déjà validés et laissez dans vos dossiers / vendor et / node_modules (je travaille avec composer et npm).

puis il suffit de créer un nouveau dépôt

git init

ajoutez votre télécommande

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

et récupérer la branche / tout cela

git fetch origin somebranch

et vérifiez-le

git checkout somebranch

alors vous devriez être au point avant l'erreur.

J'espère que cela t'aides.

Cordialement.

Je rencontre le même problème et j'utilise un moyen très simple pour le résoudre. J'ai trouvé que ces fichiers manquants existaient sur l'ordinateur de mon coéquipier.

J'ai copié ces fichiers un par un sur un serveur git (9 fichiers au total), et cela a résolu le problème.

Mes collègues et moi avons traversé plusieurs fois ce même problème et pour le résoudre nous faisons simplement les étapes que je décris ci-dessous. Ce n'est pas la solution la plus élégante qui puisse être trouvée mais elle fonctionne sans perte de données.

1. Renommez le répertoire de travail actuel. (old_project pour cet exemple).
2. Clonez le référentiel dans un nouveau répertoire à l'aide de git clone .
3. Sur la ligne de commande, remplacez le répertoire de travail par le projet nouvellement créé et basculez vers la branche sur laquelle vous avez travaillé.
4. Copiez tous les fichiers et répertoires old_project(sauf le.git répertoire) dans le répertoire du projet nouvellement créé.
5. Vérifiez l'état de votre arborescence de travail (notez qu'il y a beaucoup plus de changements que prévu), puis validez les changements.

J'espère que ça aide ...

Voici un moyen de résoudre le problème si votre dépôt public sur github.com fonctionne, mais que votre dépôt local est corrompu. Sachez que vous perdrez tous les commits que vous avez effectués dans le référentiel local.

D'accord, j'ai donc un dépôt local qui me donne ceci object empty error , et le même dépôt sur github.com, mais sans cette erreur. Donc, ce que j'ai simplement fait était de cloner le dépôt qui fonctionne à partir de github, puis de tout copier du dépôt corrompu (sauf le dossier .git), et de le coller le dépôt cloné qui fonctionne.

Cela peut ne pas être une solution pratique (puisque vous supprimez les validations locales), cependant, vous conservez le code et un contrôle de version réparé.

N'oubliez pas de sauvegarder avant d'appliquer cette approche.

Dans mon cas, il n'était pas important pour moi de conserver l'historique des validations locales. Donc, si cela s'applique à vous aussi, vous pouvez le faire comme une alternative rapide aux solutions ci-dessus:

Vous remplacez simplement le .git/répertoire corrompu par un propre.

Supposons le répertoire suivant pour votre projet avec le git corrompu: projects/corrupt_git/

1. cp projects/corrupt_git projects/backup - (facultatif) faire une sauvegarde
2. git clone [repo URL] projects/clean_git - pour que vous obteniez projects/clean_git
3. rm -rf corrupt_git/.git/ - supprimer le dossier .git corrompu
4. mv clean_git/.git/ corrupt_git/ - déplacer git propre vers corrupt_git/.git
5. git statusen projects/corrupt_git- pour vous assurer que cela a fonctionné

Copiez tout (dans le dossier contenant le .git) dans une sauvegarde, puis supprimez tout et redémarrez. Assurez-vous d'avoir la télécommande git à portée de main:

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

alors

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

Fusionnez ensuite tous les nouveaux fichiers manuellement et essayez de garder votre ordinateur allumé.

Eu le même problème après avoir vérifié le maître d'une branche propre. Après un certain temps, j'ai reconnu beaucoup de fichiers modifiés dans master. Je ne sais pas pourquoi ils ont été là, après avoir quitté une branche propre. Quoi qu'il en soit, parce que les fichiers modifiés n'avaient aucun sens pour moi, je les ai simplement cachés et l'erreur a disparu.

git:(master) git stash

si vous avez une ancienne sauvegarde et que vous êtes pressé:

créez une NOUVELLE SAUVEGARDE de votre chemin de projet actuel, git-broken.

1. bouger ton .git dans la corbeille (ne supprimez jamais)
2. copie .git de l'ancienne sauvegarde
3. git pull (créera des conflits de fusion)
4. déplacez toutes vos sources (tout ce que vous mettez dans git) dans la corbeille: ./src (ne jamais supprimer)
5. .copiez toutes vos sources (tout ce que vous mettez dans git) à partir de la NOUVELLE SAUVEGARDE
6. acceptez toutes les "fusions" à git gui, poussez et ... applaudissez!

La solution en douze étapes décrite ci-dessus m'a également aidé à sortir d'un bourrage. Merci. Les étapes clés étaient d'entrer:

git fsck --full 

et supprimez tous les objets vides

rm .git/objects/...

Puis on obtient les deux lignes du fouet:

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

Avec les valeurs retournées

git update-ref HEAD ...

À ce stade, je n'avais plus d'erreurs, j'ai donc fait une sauvegarde de mes fichiers les plus récents. Faites ensuite un git pull suivi d'un git push. Copié mes sauvegardes dans mon fichier de référentiel git et fait une autre poussée git. Cela m'a mis au courant.

J'ai corrigé mon erreur git: le fichier objet est vide par:

1. Enregistrement d'une copie de tous les fichiers que j'ai modifiés depuis mon dernier commit / push réussi,
2. Suppression et re-clonage de mon référentiel,
3. Remplacement des anciens fichiers par mes fichiers modifiés.

Espère que cela aide.

Cela m'arrive aussi presque régulièrement. Je n'ai pas établi de protocole lorsque cela se produit exactement, mais je soupçonne qu'il se produit chaque fois que ma machine virtuelle existe "de manière inattendue". Si je ferme la fenêtre de la machine virtuelle (j'utilise Ubuntu 18.04) et recommence, les choses fonctionnent toujours (?). Mais si la fenêtre de la machine virtuelle est toujours ouverte lorsque mon ordinateur portable est arrêté (système hôte Windows), je rencontre ce problème assez fréquemment.

Quant à toutes les réponses données ici:

1. merci - ils sont très utiles; J'enregistre généralement une copie locale de mon code, restaure le référentiel à distance et remets la copie de sauvegarde dans le dossier local.

2. comme le problème sous-jacent n'est pas vraiment un problème git, mais plutôt un problème VM et / ou Linux, je me demande s'il ne devrait pas y avoir un moyen de guérir la raison plutôt que les symptômes? Ce type d'erreur n'indique-t-il pas que certaines modifications du système de fichiers ne sont pas "appliquées" dans un délai raisonnable, mais uniquement mises en cache? (voir par exemple /unix/464184/are-file-edits-in-linux-directly-saved-into-disk ) - pour moi, il semble que si les machines virtuelles Linux ne le font pas fsynch leurs affaires assez fréquemment. Que ce soit un problème d'Oracle VirtualBox (qui fonctionne très bien autrement) ou du système de fichiers invité, ou de certains paramètres, que nous ignorons tous, est au-delà de mon expertise. Mais je serais heureux si quelqu'un pouvait faire la lumière là-dessus.

En fait, j'ai eu le même problème. Ayez une copie de votre code avant d'essayer.

je viens de faire git reset HEAD~

mon dernier commit a été annulé puis je l'ai recommencé, problème résolu!

Attention: Avec plus d'expérience, je me rends compte que c'est l'option nucléaire et que cela ne devrait généralement pas être fait et n'enseigne rien. Cependant, en de rares occasions pour des projets personnels, je l'ai toujours trouvé utile, donc je laisse ça de côté.

Si vous ne vous souciez pas de conserver vos validations historiques, exécutez simplement

rm -r .git

Répondez ensuite oui à toute question concernant la suppression de fichiers protégés en écriture. Problème résolu en moins d'une minute.