Chaque fois que je tire de ma télécommande, j'obtiens l'erreur suivante sur la compression. Lorsque j'exécute la compression manuelle, j'obtiens la même chose:

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

Quelqu'un sait-il quoi 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 de git fsck je reçois ceci (je ne sais pas si c'est réellement 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 objet d'arbre corrompu. Vous devrez obtenir cet objet de quelqu'un d'autre. Espérons qu'ils auront une version non corrompue.

Vous pouvez réellement le reconstruire si vous ne pouvez pas trouver une version valide de quelqu'un d'autre en devinant quels fichiers doivent y être. Vous voudrez peut-être voir si les dates et heures des objets correspondent. Ce pourraient être les blobs associés. Vous pouvez déduire la structure de l'objet arborescence de ces objets.

Jetez un œil aux screencasts Git de Scott Chacon concernant les internes 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 obtenir cet objet de quelqu'un d'autre.

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 référentiel et gardera intacte votre copie de travail locale.

Mais il présente certains inconvénients:

• Vous perdrez le record de tous les commits qui n'ont pas été poussés et devrez les réengager.
• Vous perdrez toutes les cachettes.

Le correctif

Exécutez ces commandes à partir du répertoire parent au-dessus de votre référentiel (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. Faites 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 reste 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

Foo a maintenant son .gitsous-répertoire d'origine, mais toutes les modifications locales sont toujours là. git status, commit, pull, push, Etc. travailler à nouveau comme ils le devraient.

Votre meilleur pari est probablement de simplement re-cloner à partir du référentiel distant (par exemple. Github ou autre). Malheureusement, vous perdrez toutes les validations non poussées et les modifications cachées, mais votre copie de travail doit rester intacte.

Faites d'abord une copie de sauvegarde de vos fichiers locaux. Ensuite, faites-le 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  

Validez ensuite tous les fichiers modifiés si nécessaire.

Travailler sur une machine virtuelle, dans mon ordinateur portable, la batterie est morte, a obtenu cette erreur;

erreur: fichier objet .git / objets / ce / theRef est vide erreur: fichier objet .git / objets / ce / theRef est vide fatal: objet lâche theRef (stocké 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 validés)

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

Après cela, j'ai exécuté un git status, le repo allait bien et il y avait mes changements (en attente d'être engagé, faites-le maintenant ..).

git version 1.9.1

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

Mon ordinateur est tombé en panne pendant que j'écrivais un message de validation. Après le redémarrage, l'arborescence de travail était telle que je l'avais quittée et j'ai pu valider mes modifications avec succès.

Cependant, quand j'ai essayé de courir, git statusj'ai

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 . J'avais juste besoin que Git arrête de se plaindre du fichier objet vide.

Aperçu

Le "fichier objet" est la représentation hachée de git d'un vrai fichier qui vous tient à cœur. Git pense qu'il devrait y avoir une version hachée de some/file.whateverstocké dans .git/object/xx/12345, et corriger l'erreur s'est avéré être principalement une question de déterminer le fichier que "l'objet lâche" était censé représenter.

Détails

Les options possibles semblaient être

1. Supprimer le fichier vide
2. Mettez le fichier dans un état acceptable par Git

Approche 1: supprimer le fichier objet

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

mv .git/objects/xx/12345 ..

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

Approche 2: corriger le fichier

Linus Torvalds a une excellente description de la façon de récupérer un fichier objet qui a résolu le problème pour moi. Les étapes clés 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 de quel fichier l'objet vide est censé être un hachage. Vous pouvez maintenant le réparer.

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

Après avoir fait cela, j'ai vérifié .git/objects/xx/12345qu'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 a contourné le problème.

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

git gc --aggressive --prune=now

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

exécutant simplement un git pruneproblème résolu pour moi

Je viens de vivre cela - ma machine s'est écrasée lors de l'écriture dans le référentiel 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 vers le référentiel distant, ainsi:

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 hachage (le hachage fait 40 caractères, mais pour plus de concision, j'utilise 10 ici - cela fonctionne généralement de toute façon).

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 j'y trouve le hachage:

04d44c3298

J'utilise ensuite les deux pour créer un patch pour ce commit:

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 hachage du commit avant et le hash du commit lui-même:

git diff 04d44c3298 fc1d4b0df7 > 2.patch

J'ai ensuite déménagé dans un nouveau répertoire, cloné le référentiel depuis 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, et les ai appliqués et validés avec leurs messages de validation exacts (ceux-ci peuvent être collés depuis git logou dans la gitkfenêtre):

patch -p1 < 1.patch
git commit

patch -p1 < 2.patch
git commit

Cela a restauré les choses pour moi (et notez qu'il existe probablement un moyen plus rapide de le faire pour un grand nombre de commits). Cependant, j'étais impatient de voir si l'arbre du dépôt corrompu pouvait être réparé, et la réponse est oui. 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, il y aura un point où vous pourrez exécuter fscksans erreurs. Vous aurez probablement des lignes "commit pendant" et "blob pendantes" dans le rapport, elles sont la conséquence de vos rebases et modifications dans ce dossier, et elles sont OK. Le garbage collector les supprimera en temps voulu.

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

J'obtenais également une erreur d'objet lâche corrompu.

./objects/x/x

Je l'ai corrigé avec succès en allant dans le répertoire de l'objet corrompu. J'ai vu que les utilisateurs affectés à cet objet n'étaient pas mon utilisateur git. Je ne sais pas comment cela s'est produit, mais j'ai exécuté un chown git:gitfichier sur ce fichier, puis cela a fonctionné à nouveau.

Cela peut être une solution potentielle aux problèmes de certains peuples, mais pas nécessairement tous.

J'ai eu cette erreur après que ma machine (Windows) ait décidé de se redémarrer. Heureusement, mon dépôt à distance était à jour, donc je viens de faire un nouveau git-clone ..

Runnning a git stash; git stash poprésolu mon problème

J'ai suivi bon nombre des autres étapes ici; La description de Linus sur la façon de regarder l'arbre / les objets git et de trouver ce qui manque était particulièrement utile.git-git récupère un blob corrompu

Mais à la fin, pour moi, j'avais 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 / non couverts par ce document.

En fin de compte, j'ai déplacé le conflit objects/<ha>/<hash> et utilisé git unpack-objectsavec un fichier de pack à partir d'un clone raisonnablement à jour. Il a pu restaurer les objets d'arbre manquants.

Il me reste encore beaucoup de taches qui pendent, ce qui peut être un effet secondaire du déballage des éléments précédemment archivés, et abordé dans d'autres questions ici

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  

Nous venons d'avoir le cas ici. Il est arrivé que le problème était la propriété du fichier corrompu était root au lieu de notre utilisateur normal. Cela était dû à une validation effectuée sur le serveur après que quelqu'un ait effectué 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:

$> ls -la

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

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

J'espère que ça aide!

Pour moi, cela s'est produit en raison d'une panne de courant lors d'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 ça git fsckmais ça n'a pas aidé. Étant donné que le crash s'est produit pendant un git push, il s'est manifestement produit lors de la réécriture côté client qui se produit après la mise à jour du serveur. J'ai regardé autour de moi et j'ai pensé que c2388dans mon cas, c'était un objet commit, car il était mentionné par des entrées dans .git/refs. Je savais donc que je pourrais trouverc2388 quand je regarde l'histoire (via une interface Web ou un deuxième clone).

Sur le deuxième clone, j'ai fait un git log -n 2 c2388pour identifier le prédécesseur de c2388. Ensuite, j'ai modifié manuellement .git/refs/heads/masteret .git/refs/remotes/origin/masterêtre le prédécesseur de c2388au lieu de c2388. Ensuite, je pourrais faire un git fetch. L' git fetchéchec à plusieurs reprises pour des conflits sur des objets vides. J'ai retiré chacun de ces objets vides jusqu'à ce qu'il git fetchréussisse. Cela a guéri le référentiel.

J'ai résolu ce problème: j'ai décidé de simplement copier le fichier objet non corrompu du clone de la sauvegarde vers mon référentiel d'origine. Cela a tout aussi bien fonctionné. (Au fait: 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 dépôt git distant à distance. Après de nombreux dépannages, j'ai compris qu'un de mes collègues avait fait un commit dans lequel certains fichiers en .git / objets avaient des autorisations de 440 (r - r -----) au lieu de 444 (r - r - r -). Après avoir demandé au collègue de modifier les autorisations avec des "objets chmod 444 -R" à l'intérieur du dépôt nu git, le problème a été résolu.

J'ai juste eu un problème comme ça. Mon problème particulier a été causé par un plantage du système qui a corrompu le commit le plus récent (et donc aussi la branche master). Je n'avais pas poussé et je voulais refaire ce commit. Dans mon cas particulier, j'ai pu le gérer comme ceci:

1. Faites une sauvegarde de .git/:rsync -a .git/ git-bak/
2. Vérifiez .git/logs/HEADet recherchez la dernière ligne avec un ID 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 branche à ce commit: git branch temp <commit-id>
4. refaites le commit cassé avec les fichiers dans le répertoire de travail.
5. git reset master temp pour déplacer la branche principale vers le nouveau commit que vous avez fait à l'étape 2.
6. git checkout masteret vérifiez qu'il semble bien 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 trouvés 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 raisonnablement courant, car le commit le plus récent est le plus susceptible d'être corrompu, mais si vous en perdez un autre en arrière, vous pouvez probablement toujours utiliser une méthode comme celle-ci, avec une utilisation prudente de git cherrypick, et le reflog dans .git/logs/HEAD.

Lorsque j'ai eu ce problème, j'ai sauvegardé mes modifications récentes (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 git pull. Attention cependant, cela pourrait ne pas fonctionner pour vous.

J'ai rencontré cela une fois que mon système s'est écrasé. Voici ce que j'ai fait:

(Veuillez noter que vos validations corrompues sont perdues, mais les modifications sont conservées. Vous devrez peut-être recréer ces validations à la fin de cette procédure)

• Sauvegardez votre code.
• Accédez à votre répertoire de travail et supprimez le .gitdossier.
• Maintenant, clonez la télécommande dans un autre emplacement et copiez-y le .gitdossier.
• Collez-le dans votre répertoire de travail.
• Engagez-vous comme vous le vouliez.

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