Git - How can I discard a corrupted object (if I'm OK with losing that commit)

rossmcm

I'm not what you would call a power user - I use bitbucket as an offsite backup for my repo.  Every commit I make I do as a commit and push using GitExtensions.

I have struck this error:

"C:\Program Files\Git\bin\git.exe" push --recurse-submodules=check --progress "https://bitbucket.org/..." refs/heads/master:refs/heads/master
Counting objects: 241, done.
error: bad object header
error: bad object header
Delta compression using up to 8 threads.
Compressing objects: 100% (239/239), done.
fatal: packed object 9ad6865f00b67883b0b29af71baad2913fb30f72 (stored in .git/objects/pack/pack-5497bd366ea05888c54e52b63328b34894cebb47.pack) is corrupt
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 'https://bitbucket.org/...'
Done

Press Enter or Esc to close console...

I have made the following assumptions/deductions/queries:

1. the corruption is local as the path given is local
2. I don't know if the BitBucket repo is also corrupt. How could I check this "non-invasively", i.e. without having to do a pull or a clone?  Is there a "check integrity" function on bitbucket?  I haven't found one.
3. I'm assuming the corruption is limited to one commit and probably a recent one - the reason being that it counted 241 objects and coughed after it had done 239 (although the progress shows "239/239", not "239/241").
4. the pack mentioned: pack-5497bd366ea05888c54e52b63328b34894cebb47.pack, is a shade over 1 Gb.  Have I reached some limit?  Given that the repo on BitBucket is only 46 Mb, why is the "pack" so huge?

So my question is: what are my options at this point?  If it is just one commit that is clobbered and I am happy losing that one commit from the repo and I do that, it just means I lose that "waypoint" right?  

If the cloud repo is intact, presumably a "pull" will fix the local repo.  Should I place faith in the system and try that?

If the cloud repo is intact, I could:

• rename the existing repo .git.hidden
• pull from the remote  (will this just recreate the .git folder tree, and I am presumably where I was at when the last commit and push succeeded, right?) 

Sorry for the noob questions, I have pretty much sat back and let things happen when they have done so without complaint.  Any comments/suggestions appreciated.

 

colin mcdermott

Looking into this as well as we are hitting the same issue. 

I only have the bad answer of:

rm -rf <repo> and pull it again. 

 

Git fsck; git gc --auto ; seems like a nice idea till you realise it doesn't seem to do much at all. 

 

What I found was:

git update-ref -d <broken object> 

works. but we need a way of discovering those objects. We seem to hit this a lot.