Git: “Objet en vrac corrompu”

Chaque fois que je tire de ma télécommande, j’obtiens l’erreur suivante à propos de la compression. Lorsque je lance la compression manuelle, je fais la même chose:

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

Est-ce que quelqu’un sait, que faire à ce sujet?

De cat-file j’obtiens ceci:

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

Et à partir de git fsck, je comprends (ne sais pas si c’est lié):

 $ 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 

Quelqu’un peut-il m’aider à déchiffrer cela?

On dirait que vous avez un object d’arborescence corrompu. Vous devrez obtenir cet object de quelqu’un d’autre. Espérons qu’ils auront une version non corrompue.

Vous pourriez réellement le reconstruire si vous ne trouvez pas une version valide de quelqu’un d’autre en devinant quels fichiers devraient être présents. Vous voudrez peut-être voir si les dates et heures des objects correspondent. Ceux-ci pourraient être les blobs liés. Vous pouvez déduire la structure de l’object arborescent à partir de ces objects.

Jetez un coup d’œil aux Git Screencasts de Scott Chacon concernant les internes de git. Cela vous montrera comment Git fonctionne sous le capot et comment faire ce travail de détective si vous êtes vraiment coincé et que vous ne pouvez pas l’obtenir de quelqu’un d’autre.

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

Ce correctif nécessite l’access à une copie distante non corrompue du référentiel et conservera votre copie de travail locale intacte.

Mais il a des inconvénients:

  • Vous perdrez l’enregistrement de tous les commits qui n’ont pas été validés et vous devrez les renouveler.
  • Vous allez perdre des caches.

Le correctif

Exécutez ces commandes à partir du répertoire parent au-dessus de votre repo (remplacez «foo» par le nom de votre dossier de projet):

  1. Créez une sauvegarde du répertoire corrompu:
    cp -R foo foo-backup
  2. Créez un nouveau clone du référentiel distant dans un nouveau répertoire:
    git clone git@www.mydomain.de:foo foo-newclone
  3. Supprimez le sous-répertoire .git corrompu:
    rm -rf foo/.git
  4. Déplacez le sous-répertoire .git nouvellement cloné dans foo:
    mv foo-newclone/.git foo
  5. Supprimez le rest du nouveau clone temporaire:
    rm -rf foo-newclone

Sous Windows, vous devrez 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 original .git , mais tous les changements locaux sont toujours là. git status , commit , pull , push , etc. fonctionnent à nouveau comme ils le devraient.

Votre meilleur pari est probablement de simplement re-cloner à partir du repo distant (ex. Github ou autre). Malheureusement, vous perdrez tout commit et toute modification cachée, mais votre copie de travail devrait restr intacte.

Faites d’abord une copie de sauvegarde de vos fichiers locaux. Ensuite, faites ceci depuis la racine de votre arbre de travail:

 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 

Ensuite, validez tous les fichiers modifiés si nécessaire.

Travailler sur une VM, dans mon notebook, la batterie est morte, a eu cette erreur;

erreur: fichier object .git / objects / ce / theRef est une erreur vide: fichier object .git / objects / ce / theRef est vide fatal: object en vrac theRef (stocké dans .git / objects / ce / theRef) est corrompu

J’ai réussi à remettre le repo en marche avec seulement 2 commandes et sans perdre mon travail (fichiers modifiés / modifications non validées)

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

Après cela, j’ai couru un git status , le repo s’est bien passé et il y a eu mes modifications (en attente d’être engagé, le faire maintenant ..).

git version 1.9.1

N’oubliez pas de sauvegarder toutes les modifications dont vous vous souvenez, au cas où cette solution ne fonctionnerait pas et qu’une approche plus radicale serait nécessaire.

Mon ordinateur est tombé en panne pendant que j’écrivais un message de validation. Après le redémarrage, l’arbre de travail était comme je l’avais laissé et j’ai réussi à commettre mes modifications.

Cependant, quand j’ai essayé d’exécuter git status j’ai eu

 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’essayais pas de récupérer des données . Je voulais juste que Git arrête de se plaindre du fichier object vide.

Vue d’ensemble

Le “fichier object” est la représentation hachée de git d’un fichier réel dont vous vous souciez. Git pense qu’il devrait avoir une version hachée de some/file.whatever stockée dans le .git/object/xx/12345 , et la résolution de l’erreur s’est avérée être essentiellement une question de savoir quel fichier l’object en vrac était censé représenter. .

Détails

Les options possibles semblaient être

  1. Supprimer le fichier vide
  2. Obtenez le fichier dans un état acceptable pour Git

Approche 1: Supprimer le fichier object

La première chose que j’ai essayée était juste de déplacer le fichier object

 mv .git/objects/xx/12345 .. 

Cela n’a pas marché – Git a commencé à se plaindre d’un lien rompu. Sur l’approche 2.

Approche 2: Corriger le fichier

Linus Torvalds a beaucoup écrit sur la façon de récupérer un fichier object 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’object vide est censé être un hachage. Maintenant, vous pouvez le réparer.

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

Après avoir fait cela, j’ai vérifié .git/objects/xx/12345 , il n’était plus vide et git a cessé de se plaindre.

Essayer

 git stash 

Cela a fonctionné pour moi. Il cache tout ce que vous n’avez pas commis et qui contournait le problème.

Je viens de vivre cela – ma machine est tombée en panne en écrivant sur le repository Git, et elle est devenue corrompue. Je l’ai corrigé comme suit.

J’ai commencé par regarder combien de commits je n’avais pas poussés au repo distant, donc:

 gitk & 

Si vous n’utilisez pas cet outil, il est très pratique – disponible sur tous les systèmes d’exploitation à ma connaissance. Cela a indiqué que ma télécommande manquait deux commits. J’ai donc cliqué sur l’étiquette indiquant la dernière validation à distance (généralement, ce sera /remotes/origin/master ) pour obtenir le hash (le hash a 40 caractères, mais pour abréger, j’utilise 10 ici – cela fonctionne généralement).

C’est ici:

14c0fcc9b3

Je clique ensuite sur le commit suivant (c’est-à-dire le premier que la télécommande n’a pas) et récupère le hash:

04d44c3298

J’utilise ensuite les deux pour créer un patch pour cette validation:

 git diff 14c0fcc9b3 04d44c3298 > 1.patch 

J’ai ensuite fait de même avec l’autre commit manquant, c’est-à-dire que j’ai utilisé le hash du commit avant et le hachage du commit lui-même:

 git diff 04d44c3298 fc1d4b0df7 > 2.patch 

J’ai ensuite déplacé vers un nouveau répertoire, cloné le repo de la télécommande:

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

J’ai ensuite déplacé les fichiers de correctifs dans le nouveau dossier, les ai appliqués et les ai engagés avec leurs messages de validation 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 du repo corrompu pouvait être réparé, et la réponse est la même. Avec un référentiel 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 corrompu et le remplacer par un bon. Vous devrez peut-être le faire plusieurs fois. Enfin, vous pourrez lancer fsck sans erreur. Vous aurez probablement des lignes "dangling commit" et "dangling blob" dans le rapport, qui sont une conséquence de vos rebases et modifications dans ce dossier, et sont correctes. Le ramasse-miettes les supprimera le moment venu.

Ainsi (du moins dans mon cas) un arbre corrompu ne signifie pas que les commits non compressés sont perdus.

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 également une erreur d’object en vrac corrompue.

 ./objects/x/x 

Je l’ai corrigé avec succès en allant dans le répertoire de l’object corrompu. J’ai vu que les utilisateurs assignés à cet object n’étaient pas des utilisateurs de git. Je ne sais pas comment ça s’est passé, mais j’ai couru un chown git:git sur ce fichier et ça a fonctionné à nouveau.

Cela peut être une solution potentielle pour les problèmes de certaines personnes, mais pas nécessairement tous.

Une récupération de place a résolu mon problème:

 git gc --aggressive --prune=now 

Cela prend du temps pour terminer, mais chaque object détaché et / ou index corrompu a été corrigé.

J’ai eu cette erreur après que ma machine (Windows) a décidé de redémarrer elle-même. Heureusement, mon repo à distance était à jour, alors je viens de faire un nouveau git-clone.

J’ai suivi beaucoup d’autres étapes ici; La description de Linus sur la façon de regarder l’arbre / les objects et de trouver ce qui manque est particulièrement utile. git-git récupérer blob corrompu

Mais à la fin, pour moi, les objects de l’arborescence étaient endommagés / endommagés par une défaillance partielle du disque, et les objects de l’arborescence n’étaient pas facilement récupérés / non couverts par cette doc.

À la fin, j’ai déplacé les objects// conflit objects// et utilisé git unpack-objects avec un fichier pack d’un clone raisonnablement à jour. Il était capable de restaurer les objects d’arbre manquants.

Je me suis toujours retrouvé avec beaucoup de blobs pendantes, ce qui peut être un effet secondaire du déballage des données précédemment archivées, et abordé dans d’autres questions ici.

Runnning git stash; git stash pop git stash; git stash pop corrigé mon problème

Pour moi, cela s’est produit à cause d’une panne de courant pendant que vous faisiez une 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 cela n’a pas aidé. Comme le crash s’est produit lors d’une git push , cela s’est manifestement produit lors de la réécriture côté client, ce qui se produit après la mise à jour du serveur. J’ai regardé autour de moi et ai pensé que c2388 dans mon cas était un object de validation, car il était mentionné par des entrées dans .git/refs . Donc, je savais que je pourrais trouver c2388 quand je regarde l’historique (via une interface Web ou un second clone).

Sur le second clone, j’ai fait un git log -n 2 c2388 pour identifier le prédécesseur de c2388 . J’ai ensuite modifié manuellement .git/refs/heads/master et .git/refs/remotes/origin/master pour qu’il devienne le prédécesseur de c2388 au lieu de c2388 . Ensuite, je pourrais faire un git fetch . Le git fetch échoué à plusieurs resockets pour des conflits sur des objects vides. J’ai enlevé chacun de ces objects vides jusqu’à ce que git fetch réussisse. Cela a guéri le repository.

J’ai résolu ce problème: j’ai simplement décidé de copier le fichier object non corrompu du clone de la sauvegarde dans mon référentiel d’origine. Cela a aussi bien fonctionné. (Au fait: si vous ne trouvez pas l’object dans .git / objects / par son nom, il a probablement été [pack] [pack] pour économiser de l’espace.)

J’ai eu ce même problème dans mon repo git à distance. Après beaucoup de dépannage, je me suis rendu compte qu’un de mes collègues avait fait un commit dans lequel certains fichiers dans les objects .git avaient des permissions de 440 (r – r —–) au lieu de 444 (r – r – r -). Après avoir demandé au collègue de modifier les permissions avec “chmod 444 -R objects” à l’intérieur du repository nu, le problème a été résolu.

Nous avons juste eu le cas ici. Il s’est avéré que le problème était que le propriétaire du fichier corrompu était root plutôt que notre utilisateur normal. Cela a été causé par un commit effectué sur le serveur après que quelqu’un ait fait un “sudo su -“.

Tout 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 

Allez dans le dossier où se trouve le fichier corrompu et faites un:

 $> ls -la 

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

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

J’espère que cela aide!

Je viens d’avoir un problème comme celui-ci. Mon problème particulier a été causé par un plantage du système qui a corrompu la validation la plus récente (et donc aussi la twig principale). Je n’avais pas poussé, et je voulais refaire ça. Dans mon cas particulier, j’ai pu y faire face comme ceci:

  1. Faites une sauvegarde de .git/ : rsync -a .git/ git-bak/
  2. Vérifiez le .git/logs/HEAD et trouvez la dernière ligne avec un identifiant de validation valide. Pour moi, c’était le deuxième engagement le plus récent. C’était bien, car j’avais toujours les versions du répertoire de travail du fichier, et donc toutes les versions que je voulais.
  3. Créez une twig à cette validation: git branch temp
  4. refaites la commande cassée avec les fichiers du répertoire de travail.
  5. git reset master temp pour déplacer la twig master vers le nouveau commit effectué à l’étape 2.
  6. git checkout master et vérifiez qu’il a l’air correct avec git log .
  7. git branch -d temp .
  8. git fsck --full , et il devrait maintenant être sûr de supprimer tout object corrompu trouvé par fsck.
  9. Si tout semble bon, essayez de pousser. Si cela fonctionne,

Cela a fonctionné pour moi. Je soupçonne que c’est un scénario relativement courant, car le plus récent commit est le plus susceptible d’être corrompu, mais si vous perdez un peu plus loin, vous pouvez probablement utiliser une méthode comme celle-ci, en utilisant soigneusement git cherrypick . le reflog en .git/logs/HEAD .

Lorsque j’ai eu ce problème, j’ai sauvegardé mes dernières modifications (car je savais ce que j’avais changé), puis j’ai supprimé le fichier dont il se plaignait dans .git / location. Ensuite, j’ai fait un gros effort. Attention, cela pourrait ne pas fonctionner pour vous.

Supprimez simplement le dossier .git et ajoutez-le à nouveau. Cette solution simple a fonctionné pour moi.