Git push "error: index-pack died of signal 9"

Question

I've seen a couple of similar questions to this, but haven't been able to solve my problem so am asking again.

I added a load of new files to an existing git-enabled project and am trying to push them up. When I do the push, it compresses them, then writes them, then when it gets to %100 it fails out with this error:

error: index-pack died of signal 9 332.28 MiB | 5712 KiB/s   
error: pack-objects died with strange error
error: failed to push some refs to     '<username>@<my repo location'

Things i have tried so far:

1. going to the repo and making sure everything is writable, like suggested here

2. setting the binary -delta option on some filetypes in .gitattributes

3. moving some of the folders out (and git committing the delete) with a view to adding them back individually later.

I'm kind of out of ideas... :/ Any suggestions? Grateful for any advice - max

EDIT - I've since discovered that this is due to dreamhost killing the push due to excessive memory consumption (i did this by copying my app folder to the repo server on dreamhost and doing the push from there).

I've found some pages, - that talk about a NO_MMAP=1 option in git to help prevent this, but they talk about it in terms of configuring git when it's installed. Can i set this option in an existing git install? Is it part of the config for the git-inited app that's doing the push or is it part of the config for the repo?

EDIT 2 - following the instructions on the page above, I downloaded and made my own local git binaries, with the NO_MMAP=1 option set.

I made sure these were before the dreamhost-installed versions in my path, and "which git" shows my local version, so far so good. But, i get exactly the same problem.

Do i need to do something with my repo to make the NO_MMAP option work, or is the problem something else do you think?

Answer 1

Sometimes this happens with an enterprise github as well due to load issues. I found a good way is to split the clone into two operations, which makes for lighter load on the server.

First, do a shallow clone: git clone --depth 1 myRepo.git

Next, enter the clone, and get all the rest of the history to make a full clone: cd myRepo && git fetch --unshallow

If you have an old version of git which does not support the --unshallow flag, then you can instead do something like git fetch --depth=1000000 or some other suitably large number.

Some more alternatives are discussed in this blog post: https://blogs.atlassian.com/2014/05/handle-big-repositories-git/