0

I've been work on this project locally from the late December of 2018. Now decided to push it to the remote on Github. When I ran git push -u <REMOTE_NAME> master I got the message:

fatal: bad tree object c6117da288c2323cdb4d695dcd7cdfa6f1c0118d
fatal: the remote end hung up unexpectedly
fatal: the remote end hung up unexpectedly
fatal: the remote end hung up unexpectedly
error: failed to push some refs to <REMOTE_URL>

Then after a bit research I ran git fsck

Checking object directories: 100% (256/256), done.
broken link from    tree 2e4901579b09704ecb89e685630136bf3f217bd3
              to    tree c6117da288c2323cdb4d695dcd7cdfa6f1c0118d

..... A lot of dangling blobs and commits .....

missing tree c6117da288c2323cdb4d695dcd7cdfa6f1c0118d

I've navigated to the .git/с6 and didn't find a file with the name 117da288c2323cdb4d695dcd7cdfa6f1c0118d Also had a backup of the project like a one month old. No such file there. I had no idea you should manually backup git folder.

Then I ran git cat-file -p 2e4901579b09704ecb89e685630136bf3f217bd3. The tree with the broken link to the missing tree. Got this. 

040000 tree c6117da288c2323cdb4d695dcd7cdfa6f1c0118d    players

Then somehow in the Github Desktop I've found two commits related with the missing tree. It turns out that this is a very old commits, from Dec 28 2018.

enter image description here

Fetched the SHA1 of these commits - 063babbd79d62bfc579b888b944047be6c79cb6d and bc64df9f9f734dd3450c2bef240381538cc23d6c

Then ran git cat-file -p 063babbd79d62bfc579b888b944047be6c79cb6d

tree 06d7866339756b512bd6129667a33f8c38d464c0
parent 4be4f9a68440aeedd15e56f0a0ff03ed33100753
author <NAME> 1546007706 +0300
committer <NAME> 1546007706 +0300

<FULL COMMIT MESSAGE>

Then the same command for other commit. Got the same structure. With different tree and parent

tree 07a5f4aeff3b6dc1707720c0701727864152b817
parent 063babbd79d62bfc579b888b944047be6c79cb6d

Never got this problem when committing locally. Comes up only when I was trying to push to the remote. Problem with missing tree could be related with the fact that I've stored the project in Yandex.Disk folder. To synchronize between two PC's. Just moved the project out of that folder.

It looks like the only option to not lose all commits history from Dec 28 is a manual recreation of the missing tree. Like described here. Is it so? Now I doesn't really sure what to put in the missing tree contents. How to figure out which blobs should be there?

Some other related answers that I found useful during the research:

How can I repair a git repository with a missing object?

Git: "Corrupt loose object"

How to fix git error broken link from tree to tree?

How to fix a bad git tree object

Git recovery: "object file is empty". How to recreate trees?

Listing all commits given a tree hash id

How to find the commit(s) that point to a git tree object?

edvard_munch
  • 219
  • 2
  • 12
  • Reconstructing a missing tree object is exceedingly hard unless you know **exactly** what was in it. You need to construct a tree object that hashes to the original value, otherwise it will fail fsck again, just with a different error message. – Lasse V. Karlsen Oct 09 '19 at 11:27
  • And yes, never use file/folder synchronization tools like Dropbox, Google Drive, OneDrive, Jottacloud, or similar, to synchronize git repositories. It will work until it (catastrophically) doesn't. Instead, use github for synchronization. A little late, I know, but know this for the future, and if you're synchronizing other repositories this same way, **stop doing this right now and start using github** or it will just be a matter of time before you have problems in those repositories as well. – Lasse V. Karlsen Oct 09 '19 at 11:28
  • 1
    Can you try to see if you have any in the .git folder that has a name that *contains* 117da288c2323cdb4d695dcd7cdfa6f1c0118d ? (note that I removed the first two characters from the hash since those are used to create folders to keep the files-per-folder ratio lower). Since I don't know if you're using linux, macos or Windows or whatnot I'm unable to provide the right command for you, but do a recursive file search. If Yandex handles duplicates, it might've renamed the file. – Lasse V. Karlsen Oct 09 '19 at 11:33
  • @Lasse Vågsæther Karlsen, I'm on Windows. Yes, I've decided to move out from Yandex even before I've discovered the problem. – edvard_munch Oct 09 '19 at 12:00
  • 1
    Then try `dir *117da288c2323cdb4d695dcd7cdfa6f1c0118d*.* /s` inside the .git folder, and see if it finds anything. – Lasse V. Karlsen Oct 09 '19 at 12:01
  • No luck, [screen](https://yadi.sk/i/COIEeVpG_5NC5Q) – edvard_munch Oct 09 '19 at 12:07
  • I don't know what you should do then, sorry. – Lasse V. Karlsen Oct 09 '19 at 12:12
  • @Lasse Vågsæther Karlsen, probably should just scratch all of the commits and live with it. – edvard_munch Oct 09 '19 at 12:17
  • 1
    In all honesty, if I were in your situation I would probably just commit whatever history is there to github. Also I would ZIP the existing broken repo and keep it forever locally, in case you really at some point in future need some 1 year old changes in a particular subtree. – sbat Oct 09 '19 at 12:19
  • Yes, if this was me, I would do what @sbat said. I would zip the current repository, with the problem, tuck it away, then create a fresh repository and commit whatever history would be needed to create the branches needed for ongoing work. I think you'll find that satisfying fsck in this case will be exceedingly hard. – Lasse V. Karlsen Oct 09 '19 at 12:34
  • @Lasse Vågsæther Karlsen, btw, is this a normal behavior for git, I mean, allowing to commit locally if repo is really broken? It's running `fsck` automatically before pushing to the remote? – edvard_munch Oct 09 '19 at 12:37
  • 1
    I don't know the heuristics of when it runs fsck. I could imagine it would happen when dealing with packfiles, though I'm not sure. A full fsck is not done on commit, however, and obviously not on every push or you would never have been able to push to github in the first place. TL;DR: Have no idea, but apparently it doesn't happen all the time. – Lasse V. Karlsen Oct 09 '19 at 12:47
  • 1
    @sbat, I've decided to go with you solution, you can post this as an answer. – edvard_munch Oct 10 '19 at 06:37
  • @edvard_munch well, my comment is not really a solution! :) Let's keep the question open, maybe someone will come up with better answer on how to restore individual broken commit safely (like remove it or something like this). Good luck with a project! – sbat Oct 10 '19 at 10:05

0 Answers0