GIT pull error - remote object is corrupted

Question

$ git pull

remote: fatal: object 21f3981dd35fccd28febabd96f27241eea856c50 is corrupted
error: git upload-pack: git-pack-objects died with error.
fatal: git upload-pack: aborting due to possible repository corruption on the remote side.
remote: aborting due to possible repository corruption on the remote side.
fatal: protocol error: bad pack header

Any ideas why this is failing?
When I run git --bare fsck-objects --full I just see dangling links but no broken links. Also git gc didn't help in any way. When I reclone or do pull from another clone, I don't see this error.

Are you running `git fsck` on the remote? If not, it has no bearing on the error - that's an object on the remote side, and `fsck` in your repo examines the objects in your repo. It doesn't have any way to see the ones in the remote. — Cascabel, Nov 13 '10 at 01:03
Try `git fsck --full 21f3981 ; git repack` on the remote. If this occur again, check your firewall. — J-16 SDiZ, Nov 13 '10 at 02:41
Thanks a ton Jefromi & J-16SDiZ for the information, unfortunately am not able to reproduce the error, this time a pull worked and i did nothing. Will try out the above steps when i get this error again. — Senthil A Kumar, Nov 16 '10 at 20:09
I had the same problem with bitbucket. git fsck does the trick. Thanks. — Andy, Feb 29 '12 at 00:00

score 31 · Answer 1 · answered Nov 29 '13 at 22:08

31

As Julian said see https://confluence.atlassian.com/display/FISHKB/Git+indexing+fails+due+to+bad+pack+header

It really can be a memory issue, and to make sure we don't lose the solution here it is:

git config --global pack.windowMemory "100m"
git config --global pack.SizeLimit "100m" 
git config --global pack.threads "1"

answered Nov 29 '13 at 22:08

cazcade_neil

2,011
1
14
4

2

If your server uses the smart http protocol, you might not be able to set a global config for the process. Instead, `cd` into the directory of the git repository itself and run the same commands without `--global`. – yig Jul 08 '15 at 19:09
atlassan solution mentioned here worked for me, just ssh'd, ran the 3 commands, exited, and pulled success on first try. – blamb Jan 30 '17 at 23:50

score 17 · Answer 2 · edited Jul 08 '15 at 20:17

17

Adding git config --global pack.window "0" worked for me...along with following

git config --global pack.windowMemory "100m"
git config --global pack.packSizeLimit "100m" 
git config --global pack.threads "1"

Reason:

Git clone compresses the data while cloning the repository

It compresses the data on the server memory before receiving the data/files.

If the server has out of memory you will get the above error while packing the objects

You can fix the issue by making git clone the repository without packing the objects on the server with the following.

git config --global pack.window "0"

edited Jul 08 '15 at 20:17

yig

329
3
11

answered Feb 01 '15 at 14:44

logan

7,946
36
114
185

Is this config for client or server? – Aaron Wang Jul 11 '16 at 12:13
1

@AaronWang : This is for client machine where you cloned your repository !! – logan Aug 17 '16 at 16:13

score 13 · Answer 3 · answered May 08 '12 at 04:51

13

It appears the answer is in the comments: git fsck

answered May 08 '12 at 04:51

robrich

13,017
7
36
63

It's much more likely that the server ran out of RAM creating pack files. – Jon Watte Apr 25 '16 at 16:08

score 6 · Answer 4 · answered Jan 09 '14 at 13:12

Just got this error, and spent half a day doing all the things described in the post : fsck, repack, gc, configuring memory options.

Also followed this post : http://git.kernel.org/cgit/git/git.git/tree/Documentation/howto/recover-corrupted-blob-object.txt?id=HEAD

But in the end, it was as simple as finding the damaged object(21f3981dd35fccd28febabd96f27241eea856c50 in this case) in the bare repository and replacing it with the non damaged version(which can be found in the .git folder of any of the local repositories which pulled/cloned from the bare repository.)

score 5 · Answer 5 · answered Jun 19 '17 at 06:50

5

in the client,try do it like this:

git config --global pack.windowMemory "100m"
git config --global pack.SizeLimit "100m" 
git config --global pack.threads "1"
git config --global pack.window "0"

or in the git server, try this: modify: /home/git/repositories/***.git/config，add below:

[pack]
         window = 0

answered Jun 19 '17 at 06:50

litian.zhuang

51
1
1

This solved the issue for me too, i.e. the configuration change on the server side – Sqripter Jan 18 '18 at 08:30

score 1 · Answer 6 · answered Nov 20 '13 at 14:48

1

This fix the problem for me and hope helps sombody else. :) https://confluence.atlassian.com/display/FISHKB/Git+indexing+fails+due+to+bad+pack+header

answered Nov 20 '13 at 14:48

Julian

19
3

8

Note that [link-only answers](http://meta.stackoverflow.com/tags/link-only-answers/info) are discouraged, SO answers should be the end-point of a search for a solution (vs. yet another stopover of references, which tend to get stale over time). Please consider adding a stand-alone synopsis here, keeping the link as a reference. – kleopatra Nov 20 '13 at 14:58

score 0 · Answer 7 · answered Nov 12 '16 at 07:03

For me this was because my remote server hosting the git repo had a damaged object/file. When I tried re-packing it was running out of memory. I upgraded my instance memory and then ssh-ed back in and ran

git gc

Here is the link to the documentation:

https://git-scm.com/book/uz/v2/Git-Internals-Packfiles

GIT pull error - remote object is corrupted

7 Answers7

Linked