Git pull fails with bad pack header error

git pull fails with following error

remote: Counting objects: 146, done.
remote: fatal: unable to create thread: Resource temporarily unavailable
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 how to pull successfully ?

Solution 1:

The lines beginning with remote are output from git running on the remote system. The error:

fatal: unable to create thread: Resource temporarily unavailable

... strongly suggests that you've run out of memory on the server, which can happen if you have either:

1. A repository with lots of large files, which can cause re-packing to take a lot of memory.
2. Limited virtual memory - either in general, or just for that account due to the ulimit setting

A suggestion here is to limit the amount of memory that packing may take by logging into the remote system (as the user that git runs as) and doing:

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

Solution 2:

Complementing the @Mark Longair's answer:

I had to run the following commands to fix this issue:

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

You can see more about these commands in the git documentation git config.

Solution 3:

Warning: if you see this error with Git 2.19.1, this is expected, and documented in git-for-windows/git issue 1839: "git gc crashes at 33% of counting objects" (which reports an APPCRASH both for git gc, but also for git pull), because of a mutex used in "git pack-objects", which was not correctly initialized and caused "git repack" to dump core on Windows.

As mentioned in the issue:

It affects more than just gc. I hit a variant of it with pull too:

$ git pull
remote: Enumerating objects: 3548, done.
error: git upload-pack: git-pack-objects died with error.
fatremote: aborting due to possible repository corruption on the remote side.
al: git uploadf-pack: aborting due to possible repository corruption on the remote side.
atal: protocol error: bad pack header

This is fixed in Git 2.20 (Q4 2018).
See commit 34204c8, commit 9308f45, commit ce498e0 (16 Oct 2018) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit 620b00e, 30 Oct 2018)}

pack-objects (mingw): initialize packing_data mutex in the correct spot

In 9ac3f0e (pack-objects: fix performance issues on packing large deltas, 2018-07-22, Git v2.19.0-rc1), a mutex was introduced that is used to guard the call to set the delta size. This commit even added code to initialize it, but at an incorrect spot: in init_threaded_search(), while the call to oe_set_delta_size() (and hence to packing_data_lock()) can happen in the call chain check_object() <- get_object_details() <- prepare_pack() <- cmd_pack_objects(), which is long before the prepare_pack() function calls ll_find_deltas() (which initializes the threaded search).

Another tell-tale that the mutex was initialized in an incorrect spot is that the function to initialize it lives in builtin/, while the code that uses the mutex is defined in a libgit.a header file.