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

les fichiers d'objets git ont été corrompus (comme indiqué dans d'autres réponses ainsi). Cela peut se produire lors de pannes de machines, etc.

j'ai eu la même chose. Après avoir lu les autres réponses top ici, j'ai trouvé le moyen le plus rapide de réparer le dépôt git cassé avec les commandes suivantes (exécuter dans le répertoire de travail Git qui contient le dossier .git ):

(assurez-vous de sauvegarder d'abord votre dossier de dépôt git!)

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

cela va d'abord supprimer tous les fichiers d'objets vides qui causent la corruption du dépôt dans son ensemble, puis récupérer les objets manquants (ainsi que les dernières modifications) à partir du dépôt distant, et ensuite faire une " contrôle de magasin d'objet . Qui, à ce stade, devrait réussir sans aucune erreur (il peut y avoir encore quelques avertissements!)

PS. Cette réponse suggère que vous avez une copie distante de votre dépôt git quelque part (par exemple sur GitHub) et le dépôt brisé est le dépôt local qui est lié au dépôt distant qui est encore en contact. Si ce n'est pas le cas, n'essayez pas de le corriger comme je le recommande.

j'ai résolu ce problème en enlevant les différents fichiers vides que git fsck détectait, et en lançant un simple git pull.

je trouve décevant que maintenant que même les systèmes de fichiers mettent en œuvre le journaling et d'autres techniques" transactionnelles " pour garder le fs sain, git peut arriver à 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 le périphérique.

cette erreur m'arrive quand je pousse mon commit et que mon ordinateur est suspendu. C'est de cette façon que j'ai corrigé.

Étapes pour résoudre

git status

afficher le fichier objet vide/corrompu

rm .git/objects/08/3834cb34d155e67a8930604d57d3d302d7ec12

supprimer

git status

je suis fatal: bad object HEAD message

rm .git/index

je supprimer le index pour le réinitialiser

git reset

fatal: Could not parse object '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 2 de la branche log pour montrer mon dernier 2 commit hash

git update-ref HEAD 7221fa02cb627470db163826da4265609aba47b2

je choisis le dernier commit hash

git status

affiche tout mon fichier comme deleted parce que j'ai supprimé le .git/index fichier

git reset

continuer à le réinitialiser

git status

vérifier mon fix

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

j'ai juste eu le même problème : après avoir tiré le dépôt distant, quand j'ai fait un statut git j'ai eu : "erreur: fichier objet (...) est vide" "fatal: lâche l'objet (...) est corrompu"

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

1. git stash
2. supprimer le fichier git par erreur (pas sûr que ce soit nécessaire)
3. git stash clair

Je ne sais pas exactement quelles choses c'est arrivé, mais ces instructions semblaient tout nettoyer.

parce que je dois redémarrer ma VM régulièrement, donc d'une façon ou d'une autre 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 produit, bien que cela fonctionne toujours. Puis j'ai trouvé la solution suivante plus rapide.

Étape 1

déplacez la totalité de votre dépôt dans un autre dossier.

mv current_repo temp_repo

Étape 2

cloner à nouveau le repo d'origine.

git clone source_to_current_repo.git

Étape 3

Supprimer Tout en vertu de la nouvelle repo à l'exception de la .dossier git .

Étape 4

Déplacer Tout de la temp_repo le nouveau repo à l'exception de le .dossier git .

Étape 5

supprimer le temp_repo , et nous sommes faits.

après quelques fois, je suis sûr que vous pouvez faire cette procédure très rapidement.

1. mv votre dossier app pour faire de la sauvegarde, c'est à dire mv app_folder app_folder_bk (c'est comme un git stash )
2. git clone youre_repository
3. enfin,. Ouvrez un outil de fusion (j'utilise meld diff viewer linux ou Windows Winmerge) et copiez les changements de droite ( app_folder_bk ) à gauche (nouveau app_folder ) (c'est comme un git stash appliquer ).

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

dans mon cas, cette erreur s'est produite parce que je tapais le message de propagation et que mon carnet était é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éinitialisation de la commettre où tout fonctionne bien. Dans mon cas, j'ai dû appuyer sur 4 propagations dans la tête, c'est-à-dire jusqu'à ce que ma tête soit au point avant que je tape le message de propagation. 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 dernières commits
• git cherry-pick <commit-hash> # écrémer le réinitialisées s'engage (dans mon cas sont 4 s'engage, alors, j'ai fait cette étape 4 fois) de l'ancienne direction générale de la nouvelle branche.
• git push origin backup-branch # Pousser la nouvelle branche pour être sûr que tout fonctionne bien
• git branch -D your-branch # Supprimer la branche localement ('branche' est le branche avec problème)
• git push origin :your-branch # Supprimer la branche de distance
• git branch -m backup-branch your-branch # renommer la branche de sauvegarde pour avoir le nom de la branche qui a eu le problème
• git push origin your-branch # Pousser la nouvelle branche
• git push origin :backup-branch # Supprimer la sauvegarde de la branche de distance

voici un moyen vraiment simple et rapide de traiter ce problème si vous avez un repo local avec toutes les branches et les propagations dont vous avez besoin, et si vous êtes D'accord avec la création d'un nouveau repo (ou supprimer le repo du serveur et en faire un nouveau à sa place):

1. Créer un nouveau vide repo sur le serveur (ou supprimer l'ancien repo et en créer un nouveau à sa place)
2. changez L'URL distante de votre copie locale pour pointer vers l'URL distante de la nouvelle repo.
3. poussez toutes les branches de votre repo local vers le nouveau repo serveur.

cela préserve toute l'histoire de commit et les branches que vous aviez dans votre repo local.

si vous avez des collaborateurs sur le repo, alors je pense que dans de nombreux cas, tous vos collaborateurs doivent changer L'URL distante de leur repo local, et éventuellement pousser toutes les commits qu'ils ont que le serveur n'a pas.

Cette solution a fonctionné pour moi quand j'ai rencontré ce même problème. J'ai eu un collaborateur. Après avoir poussé mon repo local vers le nouveau repo distant, il a simplement changé son repo local pour pointer vers L'URL du repo distant et tout a bien fonctionné.

je suppose que vous avez une télécommande avec tous les changements pertinents déjà poussé à elle. Je ne me souciais pas des changements locaux et je voulais simplement éviter de supprimer et de refermer un grand dépôt. Si vous avez d'importants changements locaux que vous pourriez être plus prudent.

j'ai eu le même problème après le crash de mon portable. Probablement parce que c'était un grand dépôt j'ai eu tout un peu de fichiers d'objets corrompus, qui n'apparaissaient qu'un à la fois en appelant git fsck --full , donc j'ai é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 saisir
• grep options utilisées:
  • -o retourne seulement la partie d'une ligne qui correspond réellement
  • -E active les regexes avancés
  • -m 1 assurez-vous que seul le premier match est retourné
  • [0-9a-f]{2} correspond à l'un des caractères entre 0 et 9 et a et f si deux d'entre eux se produisent ensemble
  • [0-9a-f]* correspond à un nombre quelconque des caractères entre 0 et 9 et a et f se produisant ensemble

il ne supprime encore qu'un fichier à la fois, donc vous pourrait vouloir 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 ceci est, qu'il ne produit plus rien d'utile de sorte que vous ne savez pas quand il est terminé (il ne devrait tout simplement pas faire quelque chose d'utile après un certain temps)

Pour "corriger" ce que je puis juste ajouté un appel de git fsck --full après chaque tour comme: $ 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 la moitié de la vitesse, mais il ne "état."

après cela, j'ai joué autour de certains avec les suggestions dans ce fil et finalement arrivé à un point où je pourrais git stash et git stash drop beaucoup de la substance cassée.

premier problème résolu

après j'ai encore eu le problème suivant: unable to resolve reference 'refs/remotes/origin/$branch': reference broken , qui pourrait être résolu par $ rm \repo.git\refs\remotes\origin$branch

$ git fetch

j'ai alors fait un $ git gc --prune=now

$ git remote prune origin

pour bonne mesure et

git reflog expire --stale-fix --all

se débarrasser de error: HEAD: invalid reflog entry $blubb lors de l'exécution de git fsck --full .

je rencontre le même problème, et j'utilise un moyen très simple pour le corriger. J'ai découvert que ces fichiers manquants existaient sur l'ordinateur de mon coéquipier.

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

soyons simples.. seulement dans le cas où vous avez téléchargé source à distance git repo

1. la Sauvegarde de vos .git

2. vérifier votre git

   git fsck --full
   

3. supprimer vide de fichier de l'objet (tous)

   rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e
   

4. vérifiez encore votre git.

   git fsck --full
   

5. tirez la source de la télécommande du git

   git pull origin master
   

copiez tout (dans le dossier contenant le .git) à une sauvegarde, puis supprimer tout et redémarrer. 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)

puis

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

puis fusionner tous les nouveaux fichiers manuellement, et essayer de garder votre ordinateur allumé.

avait le même problème après avoir vérifié le capitaine d'une branche propre. Après un moment, j'ai reconnu beaucoup de fichiers modifiés dans le maître. 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 juste planqués et l'erreur avait disparu.

git:(master) git stash

valider vos changements (le cas échéant) et puis juste git reset --hard

si vous avez un vieux backup et est pressé:

faites une nouvelle sauvegarde de votre chemin de projet en cours, git-broken.

1. déplacer votre .git à la corbeille (ne jamais supprimer)
2. copie .git de la VIEILLE sauvegarde
3. git pull (va créer des conflits de fusion)
4. Déplacez toutes vos sources (Tout ce que vous mettez en git) à la poubelle: ./src (jamais supprimer)
5. .copiez toutes vos sources (Tout ce que vous avez mis dans git) à partir de la nouvelle sauvegarde
6. accepter tous les "fusionne" à git gui , pousser et... tapez dans vos mains!

la solution en douze étapes décrite ci-dessus m'a aussi aidé à sortir d'une impasse. Grâce. Les étapes clés étaient d'entrer:

git fsck --full 

et supprimer tous les objets vides

rm .git/objects/...

puis obtenir les deux lignes de la poulie:

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

avec les valeurs retournées

git update-ref HEAD ...

à ce point je n'avais plus d'erreurs, donc j'ai fait une sauvegarde de mes fichiers les plus récents. Puis faire un git pull suivi par un git push. J'ai copié mes sauvegardes dans mon fichier de dépôt git et j'ai fait une autre poussée git. Cela m'a actuelle.

mes collègues et moi avons traversé plusieurs fois avec 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 peut être trouvé, mais il fonctionne sans perte de données.

1. renommer le répertoire de travail actuel. ( old_project pour cet exemple).
2. cloner le dépôt dans un nouveau répertoire en utilisant git clone .
3. sur la ligne de commande, Changer le répertoire de travail pour le projet nouvellement créé et passer à la branche sur laquelle vous avez travaillé.
4. copier tous les fichiers et répertoires dans old_project (sauf le répertoire .git ) dans le répertoire de projet nouvellement créé.
5. Vérifiez l'état de votre arborescence de travail (Notez qu'il y a beaucoup plus de changements que vous ne le pensez) et ensuite propagez les changements.

j'espère que cela aide...

voici un moyen de résoudre le problème si votre rapport public github.com ça marche, mais votre agent local est corrompu. Soyez conscient que vous perdrez tous les commits que vous avez fait dans le repo local.

D'accord, donc j'ai un rapport local qui me donne ce object empty error , et le même rapport github.com, mais sans cette erreur. Donc ce que j'ai simplement fait était de cloner la pension qui fonctionne à partir de github, et ensuite tout copié à partir de la pension corrompue (sauf la .git folder), et le coller le repo cloné qui fonctionne.

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

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

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

Si vous n'avez pas de soins sur la tenue de votre historique de commits, il suffit d'exécuter

rm-r.git

alors répondez oui à tout ce qui concerne la suppression de fichiers protégés en écriture. Problème résolu en moins d'une minute.