重新打包Git存储库失败

我在内存有限的服务器上有一个git存储库。 当我尝试从服务器克隆现有存储库时，会出现以下错误

hemi@ubuntu:$ git clone ssh://hemi@servername.dk/home/hemi/repos/articles
Initialized empty Git repository in /home/hemi/Skrivebord/articles/.git/
hemi@servername.dk's password: 
remote: Counting objects: 666, done.
remote: warning: suboptimal pack - out of memory
remote: fatal: Out of memory, malloc failed
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: early EOF
fatal: index-pack failed
hemi@ubuntu:$ 

为了处理此错误，我尝试重新打包原始存储库（根据）。但是它没有重新打包存储库，而是描述了如何使用“gitpackobjects”命令

hemi@servername：~/repos/articles$git repack-a-d——窗口内存10米——最大包大小100米
用法：git包对象[{-q |--progress |--all progress}]
[--暗示所有进展]
[--max pack size=N][--local][--incremental]
[--window=N][--window memory=N][--depth=N]
[--无重用增量][--无重用对象][--增量基偏移]
[--threads=N][--非空[--revs[--unpacket |--all]*]
[--reflog][--stdout |基名称][--include标记]
[--保持不可接近|--打开不可接近的包装
[我使用的是git版本1.7.0.4，它接受此命令。git版本1.6可能不接受此命令

hemi@servername:~/repos/articles$ git repack -a -d --window-memory 10m --max-pack-size 100m
usage: git pack-objects [{ -q | --progress | --all-progress }]
        [--all-progress-implied]
        [--max-pack-size=N] [--local] [--incremental]
        [--window=N] [--window-memory=N] [--depth=N]
        [--no-reuse-delta] [--no-reuse-object] [--delta-base-offset]
        [--threads=N] [--non-empty] [--revs [--unpacked | --all]*]
        [--reflog] [--stdout | base-name] [--include-tag]
        [--keep-unreachable | --unpack-unreachable 
        [<ref-list | <object-list]

尝试使用一些随机提交创建一个新的存储库。然后使用此命令重新打包。
我使用以下步骤解决了此问题

hemi@servername:~/repos/articles$ git repack -a -d --window-memory 10m --max-pack-size 100m
usage: git pack-objects [{ -q | --progress | --all-progress }]
        [--all-progress-implied]
        [--max-pack-size=N] [--local] [--incremental]
        [--window=N] [--window-memory=N] [--depth=N]
        [--no-reuse-delta] [--no-reuse-object] [--delta-base-offset]
        [--threads=N] [--non-empty] [--revs [--unpacked | --all]*]
        [--reflog] [--stdout | base-name] [--include-tag]
        [--keep-unreachable | --unpack-unreachable 
        [<ref-list | <object-list]

已将存储库从服务器签出到我的本地计算机（通过ssh使用原始副本）
重新打包本地存储库

git重新打包-a-d——窗口内存10m——最大包装尺寸20m
在服务器上创建了一个空存储库

git init--bare
将本地存储库推送到服务器
已检查是否可以克隆服务器存储库
您的解决方案在本地和远程为您提供了一个工作副本，但当远程存储库决定重新打包自己时，将再次导致问题。幸运的是，您可以设置配置选项，以减少在这两个存储库中重新打包所需的内存量—这些选项基本上会生成您添加到其中的命令行参数重新打包时的默认选项。因此，您应该登录到远程，更改到存储库并执行以下操作：

git config pack.windowMemory 10m
git config pack.packSizeLimit 20m

您可能也希望在本地存储库上执行同样的操作（顺便说一句，我猜您的存储库非常大，或者这些机器内存很少——这些值在我看来非常低。）

值得一提的是，过去在重新打包非常大的存储库时遇到malloc失败时，我还更改了
core.packedgitWindowsSize
，
core.packedgitlimit
，
core.deltacachesize
，
pack.deltacachesize
，
pack.window
和
pack.threads
的值，但听起来像我如果您不需要任何进一步的选项：）
这并不能回答问题，但可能会有人遇到：当
包对象
被某种内存杀手（如Dreamhost上使用的内存杀手）终止时，服务器上的重新打包也可能失败：

在Dreamhost上，这似乎是由
mmap
引起的。重新打包代码使用
mmap
将一些文件的内容映射到内存中，并且由于内存杀手不够聪明，它将mmap文件计算为已用内存，在尝试
mmap
大文件时终止Git进程

解决方案是在禁用
mmap
支持的情况下编译自定义Git二进制文件（
configure NO_mmap=1
）。
无法直接访问存储库，因此无法执行重新打包，执行浅层克隆，然后逐渐获取，同时增加深度对我有帮助

git clone YOUR_REPO --depth=1
git fetch --depth=10
...
git fetch --depth=100
git fetch --unshallow    //Downloads all history allowing to push from repo

希望它仍然可以帮助别人。
我在一个私有的github.com存储库上的Ubuntu14.10和Git2.1.0上遇到了同样的问题。
（怀疑是Enterprise路由器！可在不同的wifi网络上工作，工作场所除外）

我的解决方案是，使用ssh进行git克隆（我事先设置了ssh密钥*），如下所示：

git克隆

变成：

git克隆git@github.com：USERNAME/REPOSITORYNAME.git

*：（生成ssh密钥）

ssh keygen-t rsa-C“您的电子邮件地址已注册”_github@domain.com"

然后登录github，在设置中导入ssh密钥，然后从~/.ssh/id_rsa.pub导入。
git config--global pack.window 0
感谢您提供的配置选项，我以前不知道这些选项。存储库包含大量pdf文件。存储库的总大小（包括.git目录和跟踪文件）大约是1.1 GB。所以我猜这是一个大型存储库；-）@MarkLongair:你救了我一天，先生！我正要跑去商店买一些RAM升级：特别是在Dreamhost，我不得不使用pack.windowMemory 10m pack.packSizeLimit 20m pack.deltacachesize=20m pack.threads=2和core.deltacachesize=20m core.packedgiltimit=30m。谢谢@MarkLongairI很高兴听到您解决了这个问题，但我应该警告您，当服务器决定重新打包其存储库时，您将再次遇到同样的问题。最好在远程存储库中设置配置选项（例如，如我的回答中所建议的）因此，当它自动重新打包时，您仍然不会耗尽内存。您知道是否可以将NO_MMAP=1选项添加到现有的git安装中吗？我不这么认为，它看起来像一个预处理器宏，导致生成不同的代码。但这只是一个观点，我没有研究它。我听说过企业路由器ng内容扫描和删除HTTP的连接，但从来没有HTTPS-你的也解码和重新加密HTTPS流量吗？Rup：在进入互联网之前，有两个路由器。下周，我将确切地检查该特定公司的设置情况。我验证了，因为，它在其他任何地方都没有失败（任何其他wifi网络），就在那个特定的公司。作为大量工作的最后手段，这确实奏效了。谢谢。
git clone REPO--depth=1
对我来说仍然失败，错误是
remote:由于远程存储库可能损坏而中止。
有点像石器时代的d方法
* GnuTLS recv error (-54): Error in the pull function.
* Closing connection 2jects:  31% (183/589)   
error: RPC failed; result=56, HTTP code = 200
fatal: The remote end hung up unexpectedly
fatal: protocol error: bad pack header