How to deal with Git "Could not read" error

I am getting this error in my git repository:

22:09:15 $ git status
# On branch master
error: Could not read 8124cc15c63be92d534e4cdfa33c38d54deee122
error: unable to read tree object HEAD
nothing to commit (working directory clean)

A Google search for error: unable to read tree object HEAD doesn't result in much help, this error seems to be very rare. I am not sure how to deal with it. Could it be a hard drive failure?

Edit: The output of git fsck is the following:

broken link from  commit 607328dc80e4901a55b95c683d4fbf43e6df28bf
              to    tree 8124cc15c63be92d534e4cdfa33c38d54deee122
missing tree 8124cc15c63be92d534e4cdfa33c38d54deee122
dangling tree 56b5d4a5e429d251582ec927bca7ef1225510c41
dangling tree 0259d2d38b18b6136bb6070fb41faf3624453cc6

Solution 1:

On a "broken link" message, you could follow the GitFaq recommendations:

• back up all your state so that anything you do is re-doable if you corrupt things more!
• explode any corrupt pack-files
  • See "man git-unpack-objects", and in particular the "-r" flag.
    Also, please realize that it only unpacks objects that aren't already available, so you need to move the pack-file away from its normal location first (otherwise git-unpack-objects will find all objects that are in the pack-file in the pack-file itself, and not unpack anything at all)
• replace any broken and/or missing objects
  • This is the challenging part.
    Sometimes (hopefully often!) you can find the missing objects in other copies of the repositories.
    At other times, you may need to try to find the data some other way (for example, maybe your checked-out copy contains the file content that when hashed will be the missing object?).
• make sure everything is happy with "git fsck --full"
• repack everything to get back to an efficient state again

Notes:

• missing objects can also be related to alternate (when you share objects between repositories) with git alternates (even though that can be risky).
• The JGit/Egit eclipse plugin is also known to have a few issues.
  (Update February 2012: those plugins have come a long way and are now quite stable)

Update July 2016 (7 years laters), with Git 2.10 soon to be released, you now have:

git fsck --name-objects

It helps naming the origin of those broken links

See "How to fix git error broken link from tree to tree?" for more.

Solution 2:

I had a similar issue just now. The corruption arose when my laptop did a hard power-off during a git pull. I have a remote backup repository. First I had several object files in .git/objects/??/* that were zero size. After a cp -a backup of the repository, I did this:

• remove the zero length objects
• clone the remote repository into a ../fresh/ repository

• in the broken repository, I did

  cat ../fresh/.git/objects/pack/pack-*.pack | git unpack-objects

This filled up the missing objects in the object database. The repository seems to be back up now.

Solution 3:

I had the same problem. After a lot of hair-pulling, I discovered that it was cause by changed permission to the repository's git files. I have solved it as follows:

$ cd .git
$ chmod 755 *

Done!

Solution 4:

I got a similar error in my Homebrew install’s Git repository. Rather than restoring all the missing objects one by one, I found it easier to simply delete the .git directory and create it again by re-cloning from Homebrew’s public repository. These were my steps:

1. Check what information you have in your Git repository that you won’t get by just re-cloning. For me, it was private branches, stashes, and remotes.
   • Convert stashes into real commits by creating a new branch, applying the stash, and committing with something like “[WIP]” in the name to show that it’s a stash.
   • Save branches that are not on the public remote by pushing them to a remote of your own. This could be a fork of the repository on GitHub, or just a new Git repository in a different location on your machine.
   • If you have more than one remote, save the output of git remote -v, which contains the names and URLs of your remotes, so you can manually add them back later.
2. Delete your repoistory’s .git directory (or rename it to .git-broken and delete it later). On the command-line, this is rm -rf .git.
3. Re-clone the remote directory with git clone https://github.com/Homebrew/homebrew.git or whatever URI.
4. This will have created a new sub-folder homebrew named after the repository. You want just the .git directory from that; your local files are already okay. So mv homebrew/.git .git, and then delete the homebrew folder.
5. Your Git repository should have no errors, since you recreated it from scratch. Now just restore any information you saved in the first step.
   • If you had additional remotes, add them again with git remote add <name> <url>.
   • If you backed up any branches (or stashes converted to branches) to a remote repository, pull them from that repository to your local repository.
   • If you want, you can convert the stash-branches back to stashes by rolling back the “[WIP]” commit with git reset HEAD^ and saving the working directory to a stash again with git stash save <custom-message>.

If you run git fsck, you should see no errors:

$ git fsck
Checking object directories: 100% (256/256), done.
Checking objects: 100% (197135/197135), done.
Checking connectivity: 197162, done.
$

And git stash list, git branch, and git remote -v should show the same output as before.