CODEWITHSUNDEEP
gitgit-push
Max Williams
Max Williams

Reputation: 32933

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

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?

Upvotes: 12

Views: 48618

Answers (7)

Fuad Chonora
Fuad Chonora

Reputation: 19

I had this problem when I uninstalled Xcode. But reinstalling XCode didn't resolve the issue.

Then fixed it by just running brew uninstall git

Upvotes: 1

Ben Winding
Ben Winding

Reputation: 11787

Mac Users

In my case I had used brew install git which messed up the git from xcode

Running brew uninstall git fixed the issue

Upvotes: 3

Cory McAboy
Cory McAboy

Reputation: 332

I ran into this error as well. The solution for me was the increase the memory capacity on my server. After doing so, the error went away.

Upvotes: 0

JGurtz
JGurtz

Reputation: 1095

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/

Upvotes: 9

Chris Edwards
Chris Edwards

Reputation: 3602

I had this problem, but mine was caused by problems with the Capfile - capistrano had been updated and the changes were not reflected in the capfile.

Updating the capfile to the latest standards fixed...

Upvotes: 0

El Mariachi
El Mariachi

Reputation: 11

If you're using the Dreamhost server to keep bare repositories you can add and commit locally and then rsync your .git directory up to DH. After it finishes go into the server's [repository name].git/config and change core.bare from false to true.

Not sure exactly what you'd do if you want work trees on the server, it hasn't come up for me.

Upvotes: 1

Emil Sit
Emil Sit

Reputation: 23542

Git is somewhat memory intensive for certain operations, trading memory usage to get improved disk or network performance. (See for example some discussion on this other SO question.)

In this case, I think you and your colleagues are effectively doing a different cost trade-off: you are trading off using a professionally managed Git hosting service (such as GitHub or BitBucket) for either perceived financial savings or some other convenience (perhaps deployment?).

My recommendation, if you are not comfortable following the kinds of recommendations on the wiki/blog-post that you've cited, is to move to GitHub or Bitbucket. (I think those posts offer technically accurate solutions, FWIW.) Bitbucket offers free unlimited private repositories so there's no real cost reason to use Dreamhost for your Git hosting.

If you need some sort of deployment solution to go along with the hosting, you can engineer something that takes pushes and automatically updates just the working directory to Dreamhost for hosting, without incurring the full cost of hosting a Git repository (and all of your history) on Dreamhost.

Upvotes: 5

Related Questions