8

I'm having big problems with a git repository on my local machine.

I modified a file, ran git status and the file appeared as modified. I added the file using git add . and it worked as usual. But when i was about to commit the changes, i got the following error:

error: garbage at end of loose object 'e91ce852822d32e380ed7ddd04c93066e3c600ea'
fatal: object e91ce852822d32e380ed7ddd04c93066e3c600ea is corrupted

By running git cat-file -t e91ce852822d32e380ed7ddd04c93066e3c600ea, i can see that the object is a tree.

I've seen several solutions on how to repair a corrupt blob or commit, but this is a tree, and I can't find an answer on what could have went wrong, or how to fix it.

Any help appreciated :)

Olof Johansson
  • 301
  • 1
  • 3
  • 10

3 Answers3

5

If your git repo is synchronised with an external ressource (Github) and if any solution didn't work, you can re-init your repo

what I've done :

# copy the corrupted .git dir
mv -f .git .gitback
git init
# keep your config file
cp .gitback/config .git/config
# load objects
git pull

It worked. Obviously, it's not a great solution, but it can help

Utopik
  • 3,783
  • 1
  • 21
  • 24
  • sometimes, this is all you can do. Not a great solution though, and really only acceptable on solo projects :) – James Adam Mar 28 '15 at 00:20
2

What could have gone wrong is hard to tell, and depends on your Git version and environment.
For example, in the old days, there was a zlib issue with git1.5.1 triggering that kind of message due to a legacyheaders = false settings.

As for restoring a tree from loose objects, this SO answer "How to recover Git objects damaged by hard disk failure?" illustrates a way to do it, after that a git fsck --full (as Mark Rushakoff mentions in the comment) has been performed.

git cat-file -t 6c8cae4994b5ec7891ccb1527d30634997a978ee

and check the type of the object.

If the type is tree: you could use 'git ls-tree' to recover the tree from previous backups; then 'git mktree' to write it again in your current repository.

But that suppose finding those objects either in older packs or in repository backups.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Stumbled upon that question as well, but .git/objects/pack/ is empty. How do I perform a search through older packs? – Olof Johansson Nov 22 '10 at 13:03
  • @Olof: older packs? I believe this is where the last sentence "But that suppose finding those objects either in older packs or in repository backups" comes in. Do you have any backups? – VonC Nov 22 '10 at 14:44
  • I have a backup, but unfortunately it's about a month old. How do I find them in older packs? I can't checkout an older commit either, the only thing that seems to work is git log. – Olof Johansson Nov 24 '10 at 08:04
  • @Olof does the reflog works? Is http://stackoverflow.com/questions/4176784/lost-git-history-after-reorganizing-project-folder/4262835#4262835 a possibility here? – VonC Nov 24 '10 at 08:07
  • Yes the reflog works, but I'm not sure how http://stackoverflow.com/questions/4176784/lost-git-history-after-reorganizing-project-folder/4262835#4262835 helps me? I'm able to create a new branch from the latest commit, but I can't checkout the new branch. Thanks for the help so far btw =) – Olof Johansson Nov 25 '10 at 10:45
  • Exactly. I get the same error as described in the question. This error has occurred on other repositories on the same harddrive as well. Maybe the disk is corrupted in some way? – Olof Johansson Nov 29 '10 at 08:54
  • @Olof: a disk corruption is possible. Can you reproduce the issue on another disk? – VonC Nov 29 '10 at 09:24
  • Well, it's hard to reproduce since it seems to happen randomly. But it's always been the same scenario: added some modified files, and tried to commit. But the error occurs during the commit. The strange part is that the disk is only three months old, and everything else is working fine. – Olof Johansson Nov 29 '10 at 09:56
  • Tried back and forth with different backups, but it still didn't work. I've deleted the repo and started all over. Sucks, yes, but there didn't seem to be another way to go.. Thanks for all the help though! – Olof Johansson Dec 08 '10 at 07:52
  • @Olof: sorry to read that. I assume the new repo hasn't shown the same problem so far? – VonC Dec 08 '10 at 07:55
  • 1
    No, not so far. But I think that the problem occurred because it's located on a shared network folder. I don't know much about git and shared folders, but that's the only thing that I can think of. We will soon (hopefully) change our workflow to include local development servers, so we'll get rid if the shared folder problem. – Olof Johansson Dec 15 '10 at 14:44
-2

Good morning, for my part, i Just deleted the git directory, and re-init git.

Osin
  • 485
  • 1
  • 4
  • 12