我见过几个 similar questions对此，但未能解决我的问题，所以我再次询问。
我向现有的启用 git 的项目添加了一大堆新文件，并试图将它们向上推送。当我进行推送时，它会压缩它们，然后写入它们，然后当它达到 %100 时，它会因以下错误而失败:
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'
到目前为止我尝试过的事情:
去 repo 并确保一切都是可写的，就像建议的那样here
在 .gitattributes 中的某些文件类型上设置
binary -delta选项将一些文件夹移出(并且 git 提交删除)，以便稍后将它们单独添加回来。
我有点想法...:/有什么建议吗？感谢您的任何建议 - max
编辑 - 从那以后我发现这是由于 dreamhost 因过多的内存消耗而终止了推送(我通过将我的应用程序文件夹复制到 dreamhost 上的 repo 服务器并从那里进行推送来做到这一点)。
我已经 found一些 pages , - 在 git 中讨论了一个 NO_MMAP=1 选项来帮助防止这种情况，但是他们在安装 git 时就配置 git 进行了讨论。我可以在现有的 git 安装中设置这个选项吗？它是执行推送的 git 启动的应用程序配置的一部分，还是存储库配置的一部分？
编辑 2 - 按照上面页面上的说明，我下载并制作了我自己的本地 git 二进制文件，并设置了 NO_MMAP=1 选项。
我确保这些是在我路径中的 dreamhost 安装版本之前，并且“which git”显示我的本地版本，到目前为止一切顺利。但是，我遇到了完全相同的问题。
我是否需要对我的存储库做些什么才能使 NO_MMAP 选项起作用，或者您认为还有其他问题？
最佳答案
有时，由于负载问题，企业 github 也会发生这种情况。我发现一个好方法是将克隆分成两个操作，这样可以减轻服务器上的负载。
首先，做一个浅克隆:git clone --depth 1 myRepo.git
接下来，进入克隆，并获取所有剩余的历史以进行完整克隆:cd myRepo && git fetch --unshallow
如果你有一个不支持 --unshallow 标志的旧版本的 git，那么你可以改为执行 git fetch --depth=1000000 或其他一些适当大的数字。
这篇博文中讨论了更多替代方案:https://blogs.atlassian.com/2014/05/handle-big-repositories-git/
关于Git 推送 "error: index-pack died of signal 9"，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7985124/