j'ai eu le même problème (je ne sais pas pourquoi).

ce correctif nécessite l'accès à une copie distante non corrompue du dépôt, et conservera votre copie de travail locale intacte.

mais il a quelques inconvénients:

• vous perdrez le procès-verbal de toute commission qui n'a pas été poussée, et vous devrez les réengager.
• vous perdrez toutes les cachettes.

the fix

exécutez ces commandes depuis le répertoire parent situé au-dessus de votre repo (remplacez " foo "par le nom de votre dossier de projet):

1. créer une sauvegarde du répertoire corrompu:
   
   cp -R foo foo-backup
2. Faire un nouveau clone du dépôt distant vers un nouveau répertoire:
   
   git clone git@www.mydomain.de:foo foo-newclone
3. supprimer le corrompu .Git sous-répertoire:
   
   rm -rf foo/.git
4. Déplacer le nouveau cloné .sous-répertoire git dans foo:
   
   mv foo-newclone/.git foo
5. supprimer le reste du nouveau clone temporaire:
   
   rm -rf foo-newclone

sous Windows vous devez utiliser:

• copy au lieu de cp -R
• rmdir /S au lieu de rm -rf
• move au lieu de mv

maintenant foo a son sous-répertoire d'origine .git retour, mais toutes les modifications locales sont toujours là. git status , commit , pull , push , etc. retravaillez comme il se doit.

travaillant sur une VM, dans mon carnet, batterie morte, j'ai eu cette erreur;

erreur: Fichier objet .git/objects/ce/donc est vide d'erreur: objet fichier. git/objects/ce/donc est vide fatal: lâche l'objet donc (stockée dans .git / objects/ce / theRef) est corrompu

j'ai réussi à faire fonctionner le repo avec seulement 2 commandes et sans perdre mon travail (fichiers modifiés/changements non engagés)

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

après que j'ai couru un git status , le repo était très bien et il y avait mes changements (attendant d'être engagé, le faire maintenant..).

Git version 1.9.1

n'oubliez pas de sauvegarder tous les changements dont vous vous souvenez, juste au cas où cette solution ne fonctionne pas et une approche plus radicale est nécessaire.

mon ordinateur s'est crashé pendant que j'écrivais un message de propagation. Après le redémarrage, l'arbre de travail était comme je l'avais laissé et j'ai été capable de propager avec succès mes modifications.

Toutefois, lorsque j'ai essayé d'exécuter git status je suis

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

contrairement à la plupart des autres réponses, je n'ai pas essayé de récupérer des données . J'avais juste besoin que Git arrête de se plaindre du fichier vide.

vue D'ensemble

le "fichier objet" est la représentation hachée par git d'un vrai fichier dont vous vous souciez. Git pense qu'il devrait avoir une version hachée de some/file.whatever stockée dans .git/object/xx/12345 , et corriger l'erreur s'est avéré être principalement une question de comprendre quel fichier l ' "objet en vrac" était censé représenter.

détails

options possibles semblaient être

1. supprimer le fichier vide
2. Obtenir le fichier dans un état acceptable pour Git

approche 1: supprimer le fichier d'objet

la première chose que j'ai essayé était de déplacer le fichier objet

mv .git/objects/xx/12345 ..

qui n'a pas fonctionné - git a commencé à se plaindre d'un lien brisé. En approche 2.

approche 2: Correction du fichier

Linus Torvalds a une grande écriture de comment récupérer un objet fichier qui a résolu le problème pour moi. Les principales étapes sont résumées ici.

$> # 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

cela vous indique quel fichier l'objet vide est supposé être un hachage de. Maintenant, vous pouvez le réparer.

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

après avoir fait cela j'ai coché .git/objects/xx/12345 , il n'était plus vide, et git a cessé de se plaindre.

Essayer

git stash

ça a marché pour moi. Il cache tout ce que vous n'avez pas commis et qui a contourné le problème.

je viens de l'expérimenter - ma machine s'est écrasée en écrivant au git repo, et elle est devenue corrompue. J'ai corrigé comme suit.

j'ai commencé par regarder combien de commits Je n'avais pas poussé à la télécommande, donc:

gitk &

Si vous n'utilisez pas cet outil, il est très pratique disponible sur tous les systèmes d'exploitation pour autant que je sais. Ceci indique que ma télécommande manquait deux commits. J'ai donc cliqué sur l'étiquette indiquant la dernière commande à distance (habituellement /remotes/origin/master ) pour obtenir le hash (le hash est de 40 caractères, mais pour être bref j'utilise 10 ici - cela fonctionne généralement de toute façon).

le voici:

14c0fcc9b3

je clique alors sur la propagation suivante (c.-à-d. la première que la télécommande n'a pas) et j'y obtiens le hachage:

04d44c3298

j'utilise alors les deux pour faire un patch pour cette propagation:

git diff 14c0fcc9b3 04d44c3298 > 1.patch

j'ai fait de même avec les autres commit manquantes, c'est-à-dire que j'ai utilisé le hachage de la commit avant et le hachage de la commit elle-même:

git diff 04d44c3298 fc1d4b0df7 > 2.patch

j'ai alors déménagé dans un nouveau répertoire, cloné le repo à partir de la télécommande:

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

j'ai ensuite déplacé les fichiers patch dans le nouveau dossier, et je les ai appliqués et engagés avec leurs messages de propagation exacts (ceux-ci peuvent être collés à partir de git log ou de la fenêtre gitk ):

patch -p1 < 1.patch
git commit

patch -p1 < 2.patch
git commit

cela a restauré des choses pour moi (et notez qu'il y a probablement un moyen plus rapide de le faire pour un grand nombre de commits). Cependant, je tenais à voir si l'arbre dans le corrompu repo peut être réparé, et la réponse est qu'il peut. Avec un repo réparé disponible comme ci-dessus, exécutez cette commande dans le dossier cassé:

git fsck 

vous obtiendrez quelque chose comme ceci:

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

pour faire la réparation, je le ferais dans le dossier cassé:

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

c'est à dire supprimer le fichier endommagé et le remplacer par une bonne. Vous devrez peut-être le faire plusieurs fois. Enfin il y aura un point où vous pouvez exécuter fsck sans erreurs. Vous aurez probablement des lignes "baldling commit" et "baldling blob" dans le rapport, celles-ci sont une conséquence de vos rebases et corrections dans ce dossier, et sont OK. Le ramasseur d'ordures les enlèvera en temps voulu.

ainsi (du moins dans mon cas) un arbre corrompu ne signifie pas que les propagations Non écrasées sont perdues.

en réponse à @user1055643 manquant la dernière étape:

$ 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  

je recevais aussi une erreur d'objet libre corrompu.

./objects/x/x

j'ai réussi à le corriger en entrant dans le répertoire de l'objet corrompu. J'ai vu que les utilisateurs assignés à cet objet étaient et non de mon utilisateur git. Je ne sais pas comment c'est arrivé, mais j'ai lancé un chown git:git sur ce fichier et ça a fonctionné à nouveau.

il s'agit peut-être d'une solution potentielle pour certaines questions des peuples, mais pas nécessairement pour toutes.

Un garbage collection résolu mon problème:

git gc --aggressive --prune=now

prend un certain temps à compléter, mais chaque objet lâche et/ou index corrompu a été corrigé.

j'ai eu cette erreur après que ma machine (windows) ait décidé de redémarrer elle-même. Heureusement, mon dossier était à jour, alors j'ai fait un nouveau git-clone..

j'ai suivi beaucoup des autres étapes ici; la description de Linus de la façon de regarder l'arbre/les objets de git et de trouver ce qui manque était particulièrement utile. git-git récupérer les blob

mais à la fin, pour moi, j'ai eu des objets d'arbre lâches/corrompus causés par une défaillance partielle du disque, et les objets d'arbre ne sont pas si facilement récupérés/pas couverts par CE doc.

à la fin, j'ai déplacé le conflit objects/<ha>/<hash> hors du chemin, et utilisé git unpack-objects avec un fichier pack d'un clone raisonnablement à jour. Il a pu restaurer les objets manquants de l'arbre.

M'a encore laissé avec beaucoup de taches pendantes, ce qui peut être un effet secondaire de déballer des choses précédemment archivées, et abordé dans d'autres questions ici

Marche git stash; git stash pop résolu mon problème

pour moi, cela s'est produit à cause d'une panne de courant alors que je faisais un git push .

les messages ressemblaient à ceci:

$ 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

j'ai essayé des choses comme git fsck mais ça n'a pas aidé. Depuis le crash s'est produit lors d'un git push , cela s'est évidemment produit lors de la réécriture du côté client qui se produit après la mise à jour du serveur. J'ai regardé autour et j'ai pensé que c2388 dans mon cas était un objet commit, parce qu'il a été référé par les rubriques .git/refs . Donc je savais que je serais capable de trouver c2388 quand je regarde l'histoire (à travers une interface web ou un deuxième clone).

sur le second clone j'ai fait un git log -n 2 c2388 pour identifier le prédécesseur de c2388 . Puis j'ai modifié manuellement .git/refs/heads/master et .git/refs/remotes/origin/master pour être le prédécesseur de c2388 au lieu de c2388 . Alors je pourrais faire un git fetch . Le git fetch a échoué à plusieurs reprises pour des conflits sur des objets vides. J'ai enlevé chacun de ces objets vides jusqu'à ce que git fetch réussisse. Cela a guéri le dépôt.

j'ai résolu de cette façon: J'ai décidé de simplement copier le fichier objet non corrompu du clone de la sauvegarde vers mon dépôt original. Cela a fonctionné tout aussi bien. (En passant: Si vous ne pouvez pas trouver l'objet dans .git/objects/ par son nom, il a probablement été [emballé][pack] pour économiser de l'espace.)

j'ai eu ce même problème dans mon git repo à distance. Après beaucoup de dépannage, j'ai compris qu'un de mes collègues avait fait un engagement dans lequel certains fichiers .git / objects avait des permissions de 440 (r--r - - - -) au lieu de 444 (r--r--r--). Après avoir demandé au collaborateur de changer les permissions avec "chmod 444-R objects" à l'intérieur du git repo nu, le problème a été corrigé.

nous venons d'avoir l'affaire ici. Il s'est produit que le problème était la propriété du fichier corrompu était root au lieu de notre utilisateur normal. Ceci a été causé par un commit sur le serveur après que quelqu'un a fait un "sudo su --".

d'abord, identifiez votre fichier corrompu avec:

$> git fsck --full

Vous devriez recevoir une réponse comme celle-ci:

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

Aller dans le dossier où le fichier corrompu est et faire un:

$> ls -la

Vérifiez la propriété du fichier corrompu. Si c'est différent, retournez à la racine de votre pension et faites un:

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

Espère que cela aide!

je viens d'avoir un problème comme celui-ci. Mon problème particulier a été causé par un crash du système qui a corrompu la propagation la plus récente (et donc aussi la branche principale). Je n'avais pas poussé, et je voulais refaire cet engagement. Dans mon cas particulier, j'ai pu le traiter comme ceci:

1. faire une sauvegarde de .git/ : rsync -a .git/ git-bak/
2. cochez .git/logs/HEAD , et trouvez la dernière ligne avec un identifiant de propagation valide. Pour moi, c'était la deuxième la plus récente s'engager. C'était bien, parce que j'avais encore les versions du répertoire de travail du fichier, et donc toutes les versions que je voulais.
3. faire une branche à ce commit: git branch temp <commit-id>
4. re-faire la brisure de s'engager avec les fichiers dans le répertoire de travail.
5. git reset master temp pour déplacer la branche master vers le nouveau commit que vous avez fait à l'étape 2.
6. git checkout master et vérifiez qu'il semble à droite avec git log .
7. git branch -d temp .
8. git fsck --full , et il devrait maintenant être sûr de supprimer tous les objets corrompus que fsck trouve.
9. si tout semble bon, essayez de pousser. Si cela fonctionne,

ça a marché pour moi. Je soupçonne qu'il s'agit d'un scénario assez courant, puisque la propagation la plus récente est la plus susceptible d'être corrompue, mais si vous en perdez une plus loin, vous pouvez probablement encore utiliser une méthode comme ceci, avec l'utilisation prudente de git cherrypick , et le refrog dans .git/logs/HEAD .

Quand j'ai eu ce problème j'ai sauvegardé mes dernières modifications (que j'ai su que j'avais changé) puis supprimé ce fichier, il se plaint .git/emplacement. Puis j'ai fait un coup de git. Prenez soin cependant, cela pourrait ne pas fonctionner pour vous.

il suffit de supprimer .git dossier et l'ajouter à nouveau. Cette solution simple a fonctionné pour moi.