Git: "Corrupt loose object"

Whenever I pull from my remote, I get the following error about compression. When I run the manual compression, I get the same:

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

Does anyone know, what to do about that?

From cat-file I get this:

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

And from git fsck I get this ( don't know if it's actually related):

$ 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

Can anyone help me decipher this?

I had the same problem (don't know why).

This fix requires access to an uncorrupted remote copy of the repository, and will keep your locally working copy intact.

But it has some drawbacks:

You will lose the record of any commits that were not pushed, and will have to recommit them.
You will lose any stashes.

The fix

Execute these commands from the parent directory above your repo (replace 'foo' with the name of your project folder):

Create a backup of the corrupt directory:
cp -R foo foo-backup
Make a new clone of the remote repository to a new directory:
git clone [email protected]:foo foo-newclone
Delete the corrupt .git subdirectory:
rm -rf foo/.git
Move the newly cloned .git subdirectory into foo:
mv foo-newclone/.git foo
Delete the rest of the temporary new clone:
rm -rf foo-newclone

On Windows you will need to use:

copy instead of cp -R
rmdir /S instead of rm -rf
move instead of mv

Now foo has its original .git subdirectory back, but all the local changes are still there. git status, commit, pull, push, etc. work again as they should.

Your best bet is probably to simply re-clone from the remote repository (i.e., GitHub or other). Unfortunately you will lose any unpushed commits and stashed changes, however your working copy should remain intact.

First make a backup copy of your local files. Then do this from the root of your working tree:

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

Then commit any changed files as necessary.

Working on a VM, in my notebook, battery died, got this error;

error: object file .git/objects/ce/theRef is empty error: object file .git/objects/ce/theRef is empty fatal: loose object theRef (stored in .git/objects/ce/theRef) is corrupt

I managed to get the repo working again with only 2 commands and without losing my work (modified files/uncommitted changes)

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

After that I ran a git status, the repo was fine and there were my changes (waiting to be committed, do it now..).

git version 1.9.1

Remember to backup all changes you remember, just in case this solution doesn't works and a more radical approach is needed.

Looks like you have a corrupt tree object. You will need to get that object from someone else. Hopefully they will have an uncorrupted version.

You could actually reconstruct it if you can't find a valid version from someone else by guessing at what files should be there. You may want to see if the dates & times of the objects match up to it. Those could be the related blobs. You could infer the structure of the tree object from those objects.

Take a look at Scott Chacon's Git Screencasts regarding git internals. This will show you how git works under the hood and how to go about doing this detective work if you are really stuck and can't get that object from someone else.

My computer crashed while I was writing a commit message. After rebooting, the working tree was as I had left it and I was able to successfully commit my changes.

However, when I tried to run git status I got

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

Unlike most of the other answers, I wasn't trying to recover any data. I just needed Git to stop complaining about the empty object file.

Overview

The "object file" is Git's hashed representation of a real file that you care about. Git thinks it should have a hashed version of some/file.whatever stored in .git/object/xx/12345, and fixing the error turned out to be mostly a matter of figuring out which file the "loose object" was supposed to represent.

Details

Possible options seemed to be

Delete the empty file
Get the file into a state acceptable to Git

Approach 1: Remove the object file

The first thing I tried was just moving the object file

mv .git/objects/xx/12345 ..

That didn't work - Git began complaining about a broken link. On to Approach 2.

Approach 2: Fix the file

Linus Torvalds has a great writeup of how to recover an object file that solved the problem for me. Key steps are summarized here.

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

This tells you what file the empty object is supposed to be a hash of. Now you can repair it.

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

After doing this I checked .git/objects/xx/12345, it was no longer empty, and Git stopped complaining.