Git: “Corrompus lâche objet”

Chaque fois que je sors de ma télécommande, j'obtiens l'erreur suivante à propos de la compression. Quand je lance la compression manuelle, je reçois le même:

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

Personne ne sait, quoi faire à ce sujet?

De chat-fichier 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 obtenir ceci ( ne sais pas si c'est réellement liés):

$ 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 ce?

Avez-vous essayé de regarder le dernier objet (45ba4ceb93bc812ef20a6630bb27e9e0b33a012a)?
Merci... mais comment faire un "look" à un objet? Encore nouveau pour git 🙂
Essayez git show.
git show me donne rien de plus que git fsck déjà fait malheureusement.
Linus Torvalds a écrit ce qui suit document utile à propos de cette erreur et comment reconstruire manuellement les gouttes si vous avez les fichiers: Comment récupérer corrompu objet blob Quelques astuces pour reconstruire les objets blob dans le but de résoudre un corrompu référentiel
Pouvez-vous ajouter des commentaires, ou de la modifier, de la accepté de répondre? Je suis exactement dans la même situation, et l'on a accepté la réponse ne semble pas contenir suffisamment de détails pour "Seulement les Travaux TM", mais plutôt de la force de me plonger dans les détails à moi-même.
git cat-file -t <SHA1> vous indiquera le type. Si non corrompu, vous pourrez alors faire git cat-file <type> <SHA1> pour voir le contenu (je l'ai utilisé pour un blob, je pense que ce sera également vous montrer le contenu d'autres types.)
Dans mon cas, c'était juste un problème d'autorisation. J'ai essayé de tirer à nouveau en tant que root et cela a fonctionné.
Connexes: stackoverflow.com/questions/801577/...

InformationsquelleAutor asgerhallas | 2010-11-23

git version-control

54

Semble que vous avez un mauvais arbre de l'objet. Vous aurez besoin d'obtenir l'objet de quelqu'un d'autre. J'espère qu'ils ont une version correct.

L'on pourrait reconstruire si vous ne pouvez pas trouver une version valide de quelqu'un d'autre en devinant ce que les fichiers doivent être là. Vous voudrez peut-être voir si les dates & fois des objets correspondent à la hauteur. Ceux-ci pourraient être liées à des gouttes. Vous pourriez en déduire la structure de l'objet de l'arborescence à partir de ces objets.

Prendre un coup d'oeil à Scott Chacon Git du Screencasts concernant git internes. Cela va vous montrer comment git fonctionne sous le capot et la façon de faire ce travail de détective si vous êtes vraiment coincé et ne peut pas obtenir l'objet de quelqu'un d'autre.
- pour être en mesure de reconstruire les objets, vous devez utiliser certaines de plomberie commandes git.
- Pourriez-vous m'indiquer les commandes que je devrais regarder? 🙂
- Une autre note... pouvez-vous (ou quelqu'un) dites-moi ce qu'est un lâche objet est réellement? L'objet n'existe pas en tant que fichier dans mon exemplaire du dépôt, mais en aucun un elses copie. Donc je ne peux pas l'obtenir à partir de quelque part d'autre, il me semble. Mais il ne semble pas fait de mal à personne, qu'ils donøt avez :-S
- il peut être stockée dans un fichier de pack. C'est la manière dont git comprime stockage d'objets en stockant les deltas. Objets lâches sont ceux qui ne sont pas dans un package pour le moment. Google pack fichiers, les fichiers d'index dans git et vous devriez être en mesure de plonger aussi profond que vous avez besoin.
- Merci beaucoup. Qui fait beaucoup de sens! Je vais plonger dans.
- Pourriez-vous fournir un lien dans votre réponse vers Chacon Git du screencasts?
- git cat-file -t <SHA1> vous indiquera le type. Si non corrompu, vous pourrez alors faire git cat-file <type> <SHA1> pour voir le contenu (je l'ai utilisé pour un blob, je pense que ce sera également vous montrer le contenu d'autres types.)
- Aussi ce post à partir de Linus décrit le processus de récupération d'un blob. Quand j'ai suivi ces instructions, si, git status responsed fatal: unable to read <SHA1> même si j'avais réussi a couru git hash-object -w <file> (sans doute parce que, par ses instructions, j'avais proposé que le fichier objet à l'écart. De retour, il m'a donné la même corrupt loose object erreur.)
- Et maintenant répéter en anglais s'il vous plaît
- les liens ne fonctionnent plus
InformationsquelleAutor Adam Dymitruk
306

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

Ce correctif nécessite l'accès à une inaltéré à distance copie du dépôt, et de garder votre localement de la copie de travail intact.

Mais il a aussi quelques inconvénients:
- Vous perdrez l'enregistrement de toutes les commits qui n'ont pas été poussé, et devront s'engager de nouveau à eux.
- Vous perdrez tous les caches.
Le correctif

Exécuter ces commandes dans le répertoire parent au-dessus de votre repo (remplacer 'foo' avec le nom de votre dossier de projet):
1. Créer une sauvegarde de la corruption répertoire:
  
  cp -R foo foo-backup
2. Faire un nouveau clone du dépôt distant vers un nouveau répertoire:
  
  git clone [email protected]:foo foo-newclone
3. Supprimer la corruption .git sous-répertoire:
  
  rm -rf foo/.git
4. Déplacer le nouveau cloné .git sous-répertoire dans foo:
  
  mv foo-newclone/.git foo
5. Supprimer le reste de la temporaire de nouveau clone:
  
  rm -rf foo-newclone
Sur 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 origine .git sous-répertoire de retour, mais tous les changements locaux sont toujours là. git status, commit, pull, push, etc. travailler à nouveau comme ils le devraient.
- Cette méthode a fonctionné pour moi. Cependant, je crois que tous les unpushed s'engage ont été perdus. Pensions de données a été épargnée.
- Oui, unpushed commettre des informations seront perdues. Mais dans les scénarios courants (pas de multiples branches locales avec unpushed changements dans d'autres, que l'actuel), toutes les plus récentes modifications de fichier (inkl. les suppressions) sont toujours sur le disque, ainsi, on peut facilement se reproduire précédente unpushed s'engage. Depuis j'ai toujours pousser après une séquence de commits, j'ai même n'a pas rencontré ce problème.
- Simple et directe. C'est, de l'OMI, la solution la plus efficace si vous ne comprenez pas tout sur git et vous ne voulez pas jouer avec votre référentiel.
- Cela affectera planqué changements?
- Je pense qu'il serait de supprimer tous les caches, car ils sont stockés sous la .git sous-répertoire.
- Dans le cas où il est submodules dans le projet, il est nécessaire d'initialisation avant de récupérer le .git dossier.
- btw, sur windows où cp et rm ne sont pas disponibles, j'ai eu du succès simplement en utilisant l'Explorateur de Windows pour supprimer et remplacer le .git sous-répertoire dans le nouveau clone.
- Tout conseil sur comment cette erreur qui s'est passé?
- Dans mon cas, j'ai utilisé git svn avant que le problème s'est produit. Et après la correction, le git-svn-branche a été perdu. Probablement, parce que c'était seulement présents sur le terrain pour gérer le dépôt svn de synchronisation. De toute façon, une fois votre solution étape-par-étape, le problème avec le fichier corrompu a été résolu et le git-svn-branche est allé. Donc, juste pour le fun, j'ai essayé de copier le .git dossier à la foo de retour à nouveau. Et curieusement, le problème ne semble pas encore ET j'ai eu le git-svn branche. Ainsi, tout est bien maintenant. Je vous remercie. +1
- Il a résolu le problème mais j'ai perdu mon importance de toutes les autres branches de master, afin de l'utiliser très très soigneusement
- Ce doit être la accepté de répondre. Plus facile que d'apprendre le fonctionnement interne de git.
- Je suis d'accord @earl3s; ce doit être la accepté de répondre. Ma question moi d'être sur une branche (qui est synchronisé avec dépôt distant). Donc, une fois arrivé à l'étape #6, j'ai eu beaucoup de fichiers modifiés (parce que j'étais sur le master). J'ai eu à effectuer ces commandes supplémentaires: git checkout -b loose-object-fix / git add --all / git commit -m "Loose object files" / git checkout <feature-branch>. J'étais alors en arrière, là où j'étais avant de le lâche objet de situation.
- Je suis d'accord que c'est la réponse la plus simple, mais vous perdez rien ne sont pas stockées dans la distance des pensions. Caches sont mentionnés, mais vous pourrait avoir plusieurs purement local des branches. Je pense que c'est un assez grand de qualification qu'il ne devrait pas être l'approche recommandée. Cependant, je pense que l'on a accepté la réponse devrait être mis à jour à dire "si vous avez rien de local, considèrent (ce) réponse".
- C'est un travail pour moi, mais mon fichier nouvellement créé montrer vide.pourrai-je reprendre le fichier nouvellement créé?
- Voulez-vous dire par "fichier nouvellement créé" un fichier qui n'a pas encore ajouté de git? Si oui, alors les étapes ci-dessus ne peut pas supprimer son contenu. Vous allez sûrement voir dans foo-backup à partir de l'étape 1, que le dossier était vide avant.
- Ce pourrait perdre tout le travail dans le local git reflog qui n'existe que sur cette copie locale du dépôt, et nulle part ailleurs.
InformationsquelleAutor cubic lettuce
195

Votre meilleur pari est probablement tout simplement re-cloner à partir de la télécommande repo (ie. Github ou autre). Malheureusement, vous perdrez toutes les unpushed s'engage et planqué changements, cependant, votre copie de travail doit rester intacte.

D'abord faire une copie de sauvegarde de vos fichiers locaux. Puis le faire à partir de 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  
```
Puis valider toute modification de fichiers que nécessaire.
- À mon humble avis, cela devrait être la accepté de répondre. Beaucoup plus facile que de supprimer les pensions de titres et de re-clonage! 🙂 Bien que vous ne perdrez aucune mise en scène s'engage...
- Évidemment, si vous étiez dans une branche autre que le maître, à la corruption qui s'est passé, remplacer master avec votre nom de la branche.
- Surtout travaillé comme c'est, mais j'étais sur une autre branche working quand il endommagé et que ces étapes ne m'a pas donné une copie locale d'une succursale autre que le maître (et oui, j'avais essayé de remplacer le maître-dessus avec working mais cela ne fonctionne pas). Fini de faire les étapes ci-dessus avec master, puis accrocher mes changements et de faire checkout -b working origin/working et éclater la cachette là. Semble avoir travaillé - merci!
- Mon référentiel a un sous-module qui n'a pas été endommagé. Ce processus a quitté le référentiel et de ses sous-module dans un état où les commandes telles que git status donné fatal: Not a git repository: submodules/my-sub/../../.git/modules/my-sub. La suppression de la sous-module du système de fichiers et de redémarrer le processus restauré à la normale. Sans doute qu'il y ait des nations unies-poussé de révisions dans submodules premier est une bonne idée...
- Je l'ai fait aujourd'hui et ne pas perdre les modifications non validées pour les fichiers 🙂 (git 2.17.1 picloc)
- Cette réponse m'a aidé à travailler sur ce problème tellement nombreuses (+de 20) fois. Merci man!
InformationsquelleAutor user1055643
108

De travail sur une machine virtuelle, dans mon ordinateur portable, la batterie est morte, eu cette erreur;

erreur: le fichier de l'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/donc) est corrompu

J'ai réussi à obtenir le repo de travailler à nouveau avec seulement 2 commandes et sans perdre mon travail (fichiers modifiés/les modifications non validées)
```
find .git/objects/-size 0 -exec rm -f {} \;
git fetch origin
```
Après que j'ai couru un git status, l'opération était bien et il y avait mes modifications (en attente d'être commis, le faire maintenant..).

git version 1.9.1

N'oubliez pas de sauvegarder toutes les modifications que vous rappelez-vous, juste au cas où cette solution ne fonctionne pas et une approche plus radicale est nécessaire.
- find .git/objects/ -size 0 -exec rm -f {} \; fonctionne pour moi 😉
- Il fonctionne pour moi aussi, et je travaille également sur une machine virtuelle.
- Eu le même problème, l'exécution de la commande, a parfaitement fonctionné pour moi sur la Menthe VM.
- Également travaillé parfaite sans avoir à faire autre chose.
- cela a fonctionné pour moi trop de travail sur une machine virtuelle
- J'ai forcer l'arrêt de ma machine virtuelle Ubuntu une fois, après que cette erreur est survenue. Cette solution a fonctionné.
- a travaillé pour moi 😉 travaillant sur un VM trop
- Pas sur une machine virtuelle, ce qui a fonctionné pour moi à de nombreuses reprises. IDK pourquoi cela continue à se produire dans mon projet actuel, mais il les corrige à chaque fois.
- Vous pourriez avoir besoin pour exécuter git symbolic-ref HEAD refs/heads/master. après la suppression de la vide d'objets.
- Je suis revenu de cette réponse, au moins 5 fois. Il continue à se produire pour moi dans VSCode, aucune idée de pourquoi c'est probablement un bug avec l'éditeur. Commentaires afin que je puisse trouver cela très utile de répondre plus facilement à l'avenir.
- Fonctionne parfaitement, c'est aussi travailler sur une machine virtuelle ici. Pas sûr de ce qui a provoqué la corruption.
- Il fonctionne pour moi
- également eu à faire un git reset --hardmais votre stratégie est le moyen le plus rapide, je pense. Merci!
- Merci beaucoup. Qui a sauvé mon travail
InformationsquelleAutor Felipe Pereira
39

Mon ordinateur est tombé en panne alors que j'écrivais un message de commit. Après le redémarrage, l'arbre de travail a été comme je l'avais laissé et j'ai été en mesure de réussir à commettre de mes modifications.

Cependant, lorsque 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'étais pas en train de récupérer toutes les données. J'ai juste besoin de Git à arrêter de se plaindre à propos de l'objet vide de fichier.

Aperçu

L'objet "fichier" est git est haché représentation d'un fichier réel que vous vous souciez. Git pense qu'il devrait avoir une version cryptée de some/file.whatever stockées dans .git/object/xx/12345, et la fixation de l'erreur s'est avéré être surtout une question de trouver le fichier "loose objet" était censé représenter.

Détails

Options possibles semblait être
1. Supprimer le fichier vide
2. Obtenir le fichier dans un état acceptable pour Git
Méthode 1: Supprimer le fichier objet

La première chose que j'ai essayé était juste de déplacer le fichier d'objet
```
mv .git/objects/xx/12345 ..
```
Qui n'ont pas de travail - git a commencé à se plaindre au sujet d'un lien brisé. À l'Approche 2.

Approche 2: Fixer le fichier

Linus Torvalds a un grand article de comment faire pour récupérer un fichier objet 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 que le fichier de l'objet vide est censé être un algorithme de 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 cessé de se plaindre.

InformationsquelleAutor declan
12

Essayer
```
git stash
```
Cela a fonctionné pour moi. Il caches quelque chose que vous n'avez pas commis et qui a obtenu de contourner le problème.
- Trop beau pour être vrai... ne fonctionne pas pour moi 😉
- Bizarre!?! est Venu à travers cette erreur ce matin. Avait commis hier, donc pas de uncommited changé. A la suite: git stash ... fatale: Impossible de créer " /home/<utilisateur>/.git/index.lock': erreur d'Entrée/sortie touch .git/a touch: ne peut pas toucher".git/a’: erreur d'Entrée/sortie sudo touch /home/guest/.git/a PAS d'ERREUR git stash Pas de changements pour enregistrer git status ... rien à commettre, répertoire de travail propre
- Je suis un peu en retard sur ce sujet, mais d'Entrée/Sortie des erreurs signifie généralement des problèmes de disque dur. Même si je suis sûr que vous avez compris cela maintenant.
InformationsquelleAutor Arthur
7

Un la collecte des ordures fixe mon problème:
```
git gc --aggressive --prune=now
```
Prend un certain temps, mais tous les lâches de l'objet et/ou corrompus indice a été corrigé.
- C'est une bonne solution. A travaillé pour moi. Mon arrêt du système accidentellement. Cependant, cette commande m'a sauvé de clonage et de tous ces lourdes tâches. Merci De Jago.
InformationsquelleAutor Jago
4

Que je vient de vivre ce - ma machine s'est écrasé pendant la rédaction du repo Git, et il est devenu corrompu. J'ai corrigé comme suit.

J'ai commencé par chercher à combien s'engage je n'avais pas poussé à la distance repo, 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 distance commit (habituellement, c'est /remotes/origin/master) pour obtenir la valeur de hachage (le hash est de 40 caractères, mais pour des raisons de concision, je suis en utilisant 10 ici - c'est généralement de toute façon).

Ici, il est:

14c0fcc9b3

Je puis cliquez sur suivant commit (c'est à dire le premier que la télécommande ne possède pas) et le haschisch:

04d44c3298

J'utilise ensuite ces deux pour faire un patch pour ce commit:
```
git diff 14c0fcc9b3 04d44c3298 > 1.patch
```
J'ai ensuite fait de même avec les autres manquant de s'engager, c'est à dire que j'ai utilisé le hachage de la validation avant et le hachage de la livraison lui-même:
```
git diff 04d44c3298 fc1d4b0df7 > 2.patch
```
J'ai ensuite déménagé dans un nouveau répertoire, cloné le dépôt à partir de la télécommande:
```
git clone [email protected]:username/repo.git
```
J'ai ensuite passé le patch fichiers dans le nouveau dossier, et les a appliqués et engagés avec leurs exacte des messages de commit (ceux-ci peuvent être collées à partir de git log ou la gitk fenêtre):
```
patch -p1 < 1.patch
git commit

patch -p1 < 2.patch
git commit
```
Cette restauré 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 réparés pensions de titres disponibles en tant que ci-dessus, exécutez cette commande dans le cassé dossier:
```
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
```
De faire la réparation, je voudrais faire cela dans le cassé dossier:
```
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 pourriez avoir à faire ce à plusieurs reprises. Enfin, il y aura un point où vous pouvez exécuter fsck sans erreurs. Vous aurez probablement "bancales commit" et "bancales blob" lignes dans le rapport, ce sont une conséquence de votre rebases et l'amende dans ce dossier, et sont OK. Le garbage collector pour les supprimer en temps voulu.

Donc (au moins dans mon cas) un arbre endommagé ne signifie pas unpushed commits sont perdus.

InformationsquelleAutor halfer
3

J'ai été faire un corrompu lâche erreur de l'objet en tant que bien.
```
./objects/x/x
```
J'ai réussi a résolu en allant dans le répertoire de la corruption de l'objet. J'ai vu que les utilisateurs affectés à cet objet a été pas mon git de l'utilisateur. Je ne sais pas comment c'est arrivé, mais j'ai couru un chown git:git sur ce fichier, puis a de nouveau fonctionné.

Cela peut être une solution possible pour certaines questions des peuples, mais pas nécessaire de tous.

InformationsquelleAutor Rebecca Dessonville
2

J'ai eu cette erreur après mon (windows) la machine a décidé de se réinitialiser.
Heureusement, ma télécommande repo a été jusqu'à date, donc j'ai juste fait une nouvelle git-clone..

InformationsquelleAutor Dean Rather
2

J'ai suivi de nombreux autres étapes ici; Linus " description de la façon de regarder l'arbre git/objects et de trouver ce qu'il manque a été particulièrement utile. git-git récupérer les blob

Mais à la fin, pour moi, j'avais lâche/l'arbre des objets causée par une partielle de la défaillance d'un disque, et des objets de l'arborescence ne sont pas si facilement récupérées/ne sont pas couverts par cette doc.

En fin de compte, j'ai déplacé le conflit objects/<ha>/<hash> hors de la voie, et utilisé git unpack-objects avec un pack de fichier à partir d'un raisonnablement à jour clone. Il a été en mesure de restaurer le manque des objets de l'arborescence.

Encore m'a laissé avec beaucoup de pendre les gouttes, qui peut être un effet secondaire de déballage déjà archivés des choses, et de les traiter dans d'autres questions ici

InformationsquelleAutor davenpcj
2

En réponse @user1055643 manque 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  
```
- est --set-en amont-à un argument valable? Je ne le pense pas!
- git branch (--set-amont=<en amont> | u <en amont>) [<branchname>]
- Si vous supprimez .git et copie du projet cloné, les pensions de fonctionner, mais pas de branches locales, ni les caches seront préservés.
InformationsquelleAutor Ertuğrul Altınboğa
2

simplement l'exécution d'un git prune résolu ce problème pour moi
- Cela a fonctionné pour moi et qui semble être la solution la plus simple. Je ne sais pas pourquoi cette réponse n'a pas obtenu plus de votes. Le seul inconvénient est que la prochaine git pull prend un peu plus longtemps que d'habitude, j'imagine, parce que c'est le remplacement de certains objets déplacés ou quelque chose.
InformationsquelleAutor Tyler Gauch
1

Runnning git stash; git stash pop fixe mon problème

InformationsquelleAutor Simonluca Landi
1

Pour moi ce qui s'est passé en raison d'une panne de courant tout en faisant un git push.

Les messages ressemblait à 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é.
Depuis l'accident qui s'est passé au cours d'une git push, il est évident qu'elle est passé au cours de réécriture sur le client, ce qui se passe après que le serveur est mis à jour. J'ai regardé autour et a trouvé que c2388 dans mon cas était un objet commit, parce qu'il a été visé par des entrées dans .git/refs. Donc je savais que je serais en mesure de trouver c2388 quand je regarde l'histoire (à travers une interface web ou de la deuxième clone).

Sur le deuxième clone, j'ai fait un git log -n 2 c2388 pour identifier le prédécesseur de c2388. Ensuite, j'ai modifié manuellement .git/refs/heads/master et .git/refs/remotes/origin/master le prédécesseur de c2388 au lieu de c2388.
Ensuite, j'ai pu faire un git fetch.
Le git fetch manqué un peu de temps pour que des conflits sur des objets vides. J'ai enlevé chacun de ces objets vides jusqu'à ce que git fetch réussi. Qui a guéri le référentiel.

InformationsquelleAutor Christian Hujer
1

J'ai résolu de cette façon:
J'ai décidé de simplement copier les corrompus fichier de l'objet à partir de la sauvegarde clone de 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.)

InformationsquelleAutor mcginn
0

J'ai eu ce même problème dans ma nu à distance repo git. Après beaucoup de dépannage, j'ai réalisé un de mes collègues avait fait un commit dans laquelle certains des fichiers .git/objects autorisations de 440 (r--r-----) au lieu de 444 (r--r--r--). Après avoir demandé à la collègue pour modifier les autorisations d'accès avec la commande "chmod 444 -R des objets" à l'intérieur de la nue-repo git, le problème était résolu.

InformationsquelleAutor konyak
0

Nous avons juste eu le cas ici. Il est arrivé que le problème était la propriété de la corruption de fichiers a la racine à la place de notre utilisateur normal. Ceci a été causé par un commit sur le serveur après que quelqu'un a fait un "sudo su --".

Tout d'abord, identifier 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érifie la propriété de la corruption de fichier. Si c'est différent, il suffit de retourner à la racine de votre repo et faites un:
```
$> sudo chown -R YOURCORRECTUSER:www-data .git/
```
Espère que cela aide!

InformationsquelleAutor Thomas Lobjoie
0

J'ai juste eu un problème de ce genre. Mon problème a été causé par une panne du système qui ont corrompu la plus récente s'engager (et donc aussi la branche master). Je n'avais pas poussé, et je voulais re-faire qui s'engagent. Dans mon cas particulier, j'ai été en mesure de traiter avec elle comme ceci:
1. Faire une sauvegarde de .git/: rsync -a .git/git-bak/
2. Vérifier .git/logs/HEAD, et de trouver la dernière ligne avec une pièce d'engager ID. Pour moi, c'était la deuxième plus récente s'engager. C'était une bonne chose, car j'avais encore le répertoire de travail de versions de ce fichier, et donc la version que je voulais.
3. Faire une branche qui s'engagent: 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 pour le nouveau commit que vous avez fait dans l'étape 2.
6. git checkout master et vérifier qu'il regarde, à droite, avec git log.
7. git branch -d temp.
8. git fsck --full, et il devrait maintenant être plus sûr de supprimer tous les objets endommagés que fsck trouve.
9. Si tout semble bon, essayer de pousser. Si cela fonctionne,
Que travaillé pour moi. Je pense que c'est un raisonnablement scénario commun, depuis le dernier commit est le plus susceptible d'être endommagé, mais si vous perdez un retour plus loin, vous pouvez probablement continuer à utiliser une méthode comme ceci, avec la prudence dans l'utilisation de git cherrypick, et le reflog dans .git/logs/HEAD.

InformationsquelleAutor naught101
0

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 en .git/emplacement. Ensuite, j'ai fait un git pull. Prenez soin cependant, cela pourrait ne pas fonctionner pour vous.

InformationsquelleAutor gareth
-6

Juste enlever .git dossier et l'ajouter à nouveau. Cette solution simple a fonctionné pour moi.
- Ce sera nuke votre dépôt local ... , aurait plutôt des effets secondaires indésirables 🙂 Merci d'éditer votre proposition et d'ajouter que d'avertissement.
- Si vous supprimez .git, et copier de la clonned projet, les pensions de fonctionner, mais pas de branches locales, ni les caches seront préservés. Aussi, un ami de la suggestion, de supprimer votre réponse complètement pour arrêter de recevoir des bas-voix.
- whoa nelly... parler à l'aide d'un bazooka pour une pince de travail.
InformationsquelleAutor Ovidiu Matan

Vous devez vous connecter pour publier un commentaire.

Le correctif

Aperçu

Détails

Méthode 1: Supprimer le fichier objet

Approche 2: Fixer le fichier