How to recover from Git orphan commit corruption

user_14355516 0
Viewed 126

I recently got an error in a git repo that I hadn't seen before. When I run a git log -- *filename*, I receive an error message:

error: inflate: data stream error (incorrect data check)
error: failed to unpack compressed delta at offset 1553801 from .git/objects/pack/pack-63394667b58dfbcf64c603738d6e4fee460e65a9.pack
fatal: packed object a205e18f2612db9d0e007d49d944d0158ed225af (stored in .git/objects/pack/pack-63394667b58dfbcf64c603738d6e4fee460e65a9.pack) is corrupt

Looking into this further, the object in question is a tree object pointed to by an orphan commit. I determined this by running git fsck, which returned a lot of results like this:

broken link from  commit 27047169d6f6dfc4b54794c2c867a17aaeb14012
              to    tree a205e18f2612db9d0e007d49d944d0158ed225af <--- this is the object above
broken link from  commit dcb7e8c97416db0e4cc8d5fbdc5bc07718841b05
              to    tree f655201563e7cfb77756b8891b7475063d7b850c
broken link from  commit 026257dfd34bdb5206b62b0ae21bf9ad1c5d0473
              to    tree 23a6dbda436b1f8d91b4ca0f695396620285ed7c
broken link from  commit 6db9a0cf7c6632a42a20f6278cfa75a8436e0d50
              to    tree efa207133f81adbca0a57ebabd711addd7f2ff58
broken link from  commit 2ab82ad80f26054fe8ea5647412051eaf95f20a1
              to    tree e010cf3090f2f1a2af61d87336c935bb89e9a56a

So far as I can tell, each of these commits is an old orphan commit from a rebase or amended commit. I see no issues with the actual commits pointed to by the current branches. If I run git gc to delete these orphans I get the same error as listed above. I don't understand why gc doesn't just delete the orphan commits even though their trees are missing.

Finally, the thing which confuses me the most is that if I clone this repo to another folder, I get the same error! I didn't think a clone was supposed to copy orphan commits.

So my question is three-fold:

  1. What is the best way to manually delete these orphan commits?
  2. Why would the error be reproduced in a cloned setup?
  3. How would something like this happen in the first place? An interrupted git gc, maybe?

Edit: Thanks to Thomas, who made me realize I was incorrect about at least some of these commits being orphaned. Looks like I'm actually dealing with corruption on commits that are in my true history.

git
1 Answers

The frame of the question is wrong - the relevant commits were not entirely orphans; some were really a part of the history graph. This explains why the issue persisted to a clone, and why git log complained, which it shouldn't have if they were all orphan commits.

I talked to a coworker, and he realized that he had run a text find-replace across the whole folder without excluding the .git folder a few days ago. I was surprised he would find a plain-text string in the pack files, but apparently he did. Since the contents of these trees no longer matched their hashes, git picked it up as corruption.

My coworker reversed his find-replace, and a git fsck now shows no errors.

user_143555160
Related