Reputation: 24964
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).
Upvotes: 102
Views: 165990
Reputation: 349
I pinpoint the objects with git describe the problem objects r png files not corrupted because they load in preview/gimp .., I git add . to stage my current version which it does but then when I tried to load into smartgit I get the lovely message, a git fsck pops the same msg, up to the previous commit all was going great
Upvotes: 0
Reputation: 131
find .git/objects/ -size 0 -exec rm -f {} \;
git fetch origin
Upvotes: 2
Reputation: 101
I have solved this issue just hard resetting the origin:
git reset --hard origin/develop
Backup is always recommended because you need to copy the modified files to the branch
Upvotes: 0
Reputation: 737
.git
foldergit clone url
.git
folder).git
folder cut and paste in your working foldergit add .
git commit -m 'update-project'
git push
Upvotes: 5
Reputation: 11
what I do is: shows what's in this repo, make sure you see a .git folder, (move first to root directory)
ls -a remove the .git folder sudo rm -r .git
make and move to a new dir where you can temporary store a new clone of the repo where you are working on.
cd ../ mkdir t007 cd t007
re-clone the repo where you are working on, and navigate to it
git clone cloneSshUrlOfGitRepo cd nameOfRepo
move the frech .git folder from the just cloned repo to the repo where you had a corrupt object, and where you deleted the .git folder. (after this stap your old repo should be up and running again, because you replaced the corrupt .git folder with a new one who should be working).
mv .git ../../nameOfRepo
now you should be able to remove the new cloned repo (because you don't need it anymore, we already moved its working .git folder in the previus step)
cd ../ sudo rm -r nameOfRepo
now you can move back to your repo where you were working on before you had this issue.
cd ../nameOfRepo
Upvotes: 1
Reputation: 970
The only thing that worked for me was to delete the git repo and configure it again:
rm -rf .git
git remote set-url origin <repo-url>
Upvotes: 1
Reputation: 464
For anyone stumbling across the same issue:
I fixed the problem by cloning the repo again at another location. I then copied my whole src dir (without .git dir obviously) from the corrupted repo into the freshly cloned repo. Thus I had all the recent changes and a clean and working repository.
Upvotes: 6
Reputation: 927
You can use "find" for remove all files in the /objects
directory with 0 in size with the command:
find .git/objects/ -size 0 -delete
Backup is recommended.
Upvotes: 83
Reputation: 6473
Recovering from Repository Corruption is the official answer.
The really short answer is: find uncorrupted objects and copy them.
Upvotes: 14
Reputation: 496902
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 pull
should 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 pop
was 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.)
Upvotes: 56