Git pull fails with bad pack header error

Question

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 ?

Maudemaudie

possible duplicate of Repack of Git repository fails – Douceur

I get this with git subtree add too – Ankledeep

Answer 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" 

Whiney

Thank you! I was receiving the same error as OP. I tried implementing pack.windowMemory and pack.SizeLimit config items, but I was still receiving the error. When I added pack.threads "1" everything was resolved! – Phillada

I started with great enthusiasm when I tried to switch from svn to git. But running from one obscure problem to problem whose fix is even more obscure, I am not sure how wise the decision was for the switch. – Swanhildas

I had a problem with that I change property pack.SizeLimit instead of pack.packSizeLimit. This solved my problem. Thank you very much!!! – Shallop

git config --global pack.windowMemory "100m" fixed my problem – Convoke

Answer 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.

Priceless

what are the default values of these parameters ? – Cuomo

According to the documentation page I mentioned above, the default value of packSizeLimit is unlimited and pack.deltaCacheSize is 256 MiB. pack.threads is not mentioned, but it's probably auto detection (same as zero). But if you want to set them to default, you can simply delete them from the global config file. – Septenary

Answer 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.

Alta

One can check the size of those object_entry – Alta

Answer 4

I was able to resolve this using following steps

Step 1. clone using lesser depth

git clone https://your_git_clone_url --depth 3

Step 2. Edit .git/config and add line for develop. This is required as after setting depth I was not able to switch remote branch other than master

[core]
    repositoryformatversion = 0
    filemode = false
    bare = false
    logallrefupdates = true
    symlinks = false
    ignorecase = true
[remote "origin"]
    url = https:<your git clone url>
    fetch = +refs/heads/master:refs/remotes/origin/master
    fetch = +refs/heads/develop:refs/remotes/origin/develop  <<--- Add this line
[branch "master"]
    remote = origin
    merge = refs/heads/master
[branch "develop"]
    remote = origin
    merge = refs/heads/develop

Step 3: get fetch

Octahedrite