57

I'm using git to manage files on a project, and keep running into this problem.

When I run git status I get the message

fatal: unable to read tree e2d920161d41631066945a3cbcd1b043de919570

As I understand it, I should check the output of git fsck, and I receive

broken link from    tree e09a42f248afff64336fbbec2523df97c26451ac
              to    tree e2d920161d41631066945a3cbcd1b043de919570
broken link from    tree e09a42f248afff64336fbbec2523df97c26451ac
              to    tree 9b0dd389bd7f9e8d257395d57e0881b7957f9698
broken link from    tree e09a42f248afff64336fbbec2523df97c26451ac
              to    tree 9e288a4ad60d63f342dfd18237980674426aa725
broken link from    tree e09a42f248afff64336fbbec2523df97c26451ac
              to    tree 2a04647337089f554fab8c49cfd37149e5f4fc9f
broken link from    tree e09a42f248afff64336fbbec2523df97c26451ac
              to    tree ea16658b45ce961adc3c3f519b0e8d9672918ca8

together with a lot of missing blob messages.

Following various resources (e.g Git - Broken Links, Missing & Dangling Trees) I have simply re-cloned the project from github and started again.

Once I have re-cloned the project, all is good for a few commits, and then the problem arises again. Re-cloning every time doesn't seem to be optimal, and seems to go against the idea of using git, and I'd like to try and understand what is going on. How can I diagnose and fix this problem?

Community
  • 1
  • 1
cmhughes
  • 651
  • 1
  • 7
  • 15
  • This doesn't sound good... You may have a disk or filesystem problem... What'd your operating system? – Chris Jan 01 '14 at 17:01
  • @Chris I'm on `Ubuntu 12.04` – cmhughes Jan 01 '14 at 17:03
  • Default `ext4` filesystem? – Chris Jan 01 '14 at 17:06
  • If I hadn't got a hardware fault, I'be looking at uninstall re-install, possibly all the way back to bare metal. – Tony Hopkinson Jan 01 '14 at 17:07
  • @Chris yes, I'm using the default filesystem – cmhughes Jan 01 '14 at 17:14
  • @cmhughes, I'd start with [a filesystem check using `fsck`](http://askubuntu.com/a/14799). Note that this must be done while the filesystem is not mounted. You may need a live CD or live USB flash drive. – Chris Jan 01 '14 at 17:18
  • @Chris thanks for your time. I have posted some details following your suggestions here: [Interpretting output from fsck](http://askubuntu.com/q/398765) – cmhughes Jan 02 '14 at 04:02
  • Seems to have been answered before - cf - http://stackoverflow.com/questions/1507463/how-to-deal-with-this-git-error , http://stackoverflow.com/questions/18515101/git-reset-fatal-unable-to-read-tree – First Zero Jan 05 '14 at 15:49
  • The fact that a re-clone fixes the issue hints at something unrelated to the file system. Check if [this guide](https://help.github.com/articles/fixing-egit-corruption) is of any help. – Luís de Sousa Jan 07 '14 at 08:21

5 Answers5

39

Following my older recommendation, it boils down to being able to find a repo which actually contains the missing elements (here full trees).
This is what is shown in "How to fix corrupted git repository?".

But if a full clone doesn't solve the problem, then it may be:

Update July 2016, with Git 2.10 soon to be release, you now have:

git fsck --name-objects

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

Community
  • 1
  • 1
VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283
  • (+1) I followed the instructions in a [competing answer](http://stackoverflow.com/a/18738164/1091649)- is it essentially the same as what you described? It seems to have worked (for now), but it seems that everything is so unstable... – cmhughes Jan 04 '14 at 15:49
  • @cmhughes yes, it is similar: it basically unpack. But if even a fresh clone get corrupted as well, that would tend to point the origin of the problem back to the "origin": the remote repo on GitHub side. – VonC Jan 04 '14 at 19:11
8

I would start with a fresh clone, then run git fsck on the unchanged, untouched clone. I'm wondering (as above) if your initial clone is corrupt, but in a way allowing you to perform a few operations before orphaning the trees.

Mark Leighton Fisher
  • 5,431
  • 2
  • 14
  • 26
4

Something that just worked for me was stashing my changes, doing a git pull, and then popping the changes back off the stash stack. My corruption might of been pretty shallow, so it probably won't work for everyone but it's worth a try.

Here's the output I got when I stashed:

work@home ~/code/project $ git stash
fatal: unable to read tree 5fd5f4d0425b42e5b478773fa643dd6fd4918188
fatal: unable to read tree 5fd5f4d0425b42e5b478773fa643dd6fd4918188
Saved working directory and index state WIP on master: d93430c Generic commit msg.
HEAD is now at d93430c An older generic message.

After that I pulled and then popped and it cleaned itself up. Again, YMMV.

risingfish
  • 314
  • 2
  • 8
3

This may or may not be the problem originally raised here, but note that you will see a "fatal: unable to read tree" error from git if the user account the git command is being run under is no longer able to read all files checked out from your repository due to an ownership/permissions issue.

So in many case the first thing to check should be that you've got ownership and permissions set correctly on the files in your working tree, as that may well fix the problem. :)

Duncan Babbage
  • 18,889
  • 3
  • 50
  • 91
2

A bit funny, but it's possible this will help someone.

I just bought a new computer and my repository was in a Dropbox folder. Turns out the .git folder was still syncing as I was trying to get to work. Once the folder finished syncing, everything was normal.

BuZZ-dEE
  • 3,875
  • 7
  • 48
  • 76
Nathan Clement
  • 798
  • 1
  • 16
  • 25