I did a Git pull when I was near my quota, and as a result (so I think), got a corrupted file:
$ git pull
walk dffbfa18916a9db95ef8fafc6d7d769c29a445aa
fatal: object d4a0e7599494bfee2b5351113895b43c351496b3 is corrupted
$ git fsck --full
bad sha1 file: .git/objects/66/b55c76947b1d38983e0944f1e6388c86f07a1b.temp
fatal: object d4a0e7599494bfee2b5351113895b43c351496b3 is corrupted
$ git cat-file -t d4a0e7599494bfee2b5351113895b43c351496b3
error: unable to find d4a0e7599494bfee2b5351113895b43c351496b3
fatal: git cat-file d4a0e7599494bfee2b5351113895b43c351496b3: bad file
How can I solve this corruption?
.git/objects/66/b55c76947b1d38983e0944f1e6388c86f07a1b.temp was zero bytes; deleting it did nothing to solve my problem (same errors).
In general, fixing corrupt objects can be pretty difficult. However, in this case, we’re confident that the problem is an aborted transfer, meaning that the object is in a remote repository, so we should be able to safely remove our copy and let git get it from the remote, correctly this time.
The temporary object file, with zero size, can obviously just be removed. It’s not going to do us any good. The corrupt object which refers to it,
d4a0e75..., is our real problem. It can be found in.git/objects/d4/a0e75.... As I said above, it’s going to be safe to remove, but just in case, back it up first.At this point, a fresh
git pullshould succeed.…assuming it was going to succeed in the first place. In this case, it appears that some local modifications prevented the attempted merge, so a
stash,pull,stash popwas in order. This could happen with any merge, though, and didn’t have anything to do with the corrupted object. (Unless there was some index cleanup necessary, and the stash did that in the process… but I don’t believe so.)