4

I migrated a repository both locally and the remote, and now I am unable to push (or do much of anything) because of a bad tree object,

> git push
error: Could not read 4218a5a380d8b6cbc7f461c22cb48ed66a92c850
fatal: bad tree object 4218a5a380d8b6cbc7f461c22cb48ed66a92c850
fatal: The remote end hung up unexpectedly

4218a5a380d8b6cbc7f461c22cb48ed66a92c850 doesn't exist on my filesystem,

> dir 4218a5a380d8b6cbc7f461c22cb48ed66a92c850 /s /p
 Volume in drive C is OS
 Volume Serial Number is xxxxxxxx
File Not Found

I have all my source code files. Is my only option now to nuke the git repo and start the history over again?

Brandon Dube
  • 428
  • 1
  • 10
  • 26
  • Have you [tried any of these options](https://stackoverflow.com/questions/9005756/how-to-fix-a-bad-git-tree-object) before you posted your question? – Tim Biegeleisen Feb 13 '18 at 02:20
  • Yes, `git reset --hard` doesn't solve the problem. – Brandon Dube Feb 13 '18 at 02:30
  • Remove the first two digits from that hex and repeat your dir command, `dir 18a5a380.... /s /p` , does that return anything? Also know that it could reside in a pack file, so your dir command is in fact not helping you at all. – Lasse V. Karlsen Feb 13 '18 at 19:02
  • I searched for `18a5a380d8b6cbc7f461c22cb48ed66a92c850`. It also does not exist. There is a commit in `git reflog --all` that points to `4218a5a380d8b6cbc7f461c22cb48ed66a92c850`, that commit is a merge into origin/master. origin/master was on github, but now my remote is bitbucket. – Brandon Dube Feb 13 '18 at 20:43
  • what does `git fsck` say? – max630 Feb 14 '18 at 12:17
  • @max630 -- at this point, I have nuked the repo and made enough changes to the code it logs that I do not want to experiment with exchanging the .git folders for fear of losing more commit history. At the time, git fsck said that commit 18a5 pointed to unreadable 4218. There were some dangling objects as well. – Brandon Dube Feb 14 '18 at 16:51

2 Answers2

3

The "nuke and pave" option is not necessarily your only option, but it may be your best one. A "bad tree object" is an unusual error and suggests that parts of your repository may be corrupted (by disk failure, or rogue process / malware / whatever overwriting your files, or attempting to store a Git repository in a dropbox folder, or who knows what). If you are going to nuke it, you might want to back it up first just in case, though.

If you're doing a git push with no options, that suggests that you have a separate copy of the repository (slightly out of date, perhaps) with most of the code in it, probably on a different machine. That separate copy elsewhere may still be good. You could check that, perhaps by cloning it to a fresh location, and then update the fresh clone with new commits made from whatever you can salvage from the damaged repository, and push those so that the new commits are added to that other repository on the other machine. Then you can really be comfortable with nuke-and-pave since you have two good copies: one in your fresh clone (the third Git in this scenario), and one on the other machine (the second Git here—the first Git is your corrupted repository).

It's also worth doing some background investigation into what corrupted the repository in the first place, since that might still be going on.

As an aside, even if the tree object 4218a5a380d8b6cbc7f461c22cb48ed66a92c850 exists as a loose object, it won't be in a file named 4218a5a380d8b6cbc7f461c22cb48ed66a92c850. It will be in a directory named 42 stored as a file named 18a5a380d8b6cbc7f461c22cb48ed66a92c850.

If the object has been packed, it won't be around as a separate file at all, but rather as a packed object in some pack file (whose name is not predictable).

torek
  • 448,244
  • 59
  • 642
  • 775
  • 2
    Other than some type of catastrophic failure (power outage at an opportune moment, exceptions and segfaults in git, etc.), the only other situation where I've gotten corrupt repositories (mercurial and git both) is through the use of folder/disk synchronization tools such as Dropbox. – Lasse V. Karlsen Feb 13 '18 at 19:03
3

There is a commit in git reflog --all that points to 4218a5a380d8b6cbc7f461c22cb48ed66a92c850, that commit is a merge into origin/master

if you have the object remotely, and you have some local work which you don't want to lose by discarding your local repository, you can git clone to a temporary directory TMP, and then copy all files from TMP/.git/objects/pack into .git/objects/pack subdirectory in your folder. Then run git fsck again to see if it helped and how many more issues there are.

max630
  • 8,762
  • 3
  • 30
  • 55
  • Unfortunately, I deleted and recreated the remote when git first became corrupted which eliminated the opportunity to restore from remote. – Brandon Dube Feb 14 '18 at 16:52
  • I was able to test this technique and it worked, thanks! This is what I was looking for, something simple yet functional. – Metafaniel Aug 09 '22 at 23:09