重新包装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:$ 为了处理这个错误，我试图重新包装原始的存储库（根据这个论坛post ）。 但不是重新包装版本库，而是描述如何使用“git pack-objects”命令。
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]
Git 1.6.5.7安装在服务器上。
您的解决scheme为您提供了本地和远程的工作副本，但是当远程存储库决定重新打包时，会再次造成问题。 幸运的是，您可以设置configuration选项，以减less在这两个存储库中重新打包所需的内存量 – 这些参数基本上使您在重新打包时添加到默认选项中的命令行参数成为可能。 所以，你应该login到远程，更改到存储库，然后执行：
git config pack.windowMemory 10m git config pack.packSizeLimit 20m
你可能想在你的本地仓库上做同样的事情。 （顺便说一下，我想你的版本库是非常大的，或者这些机器的内存很小 – 这些值对我来说似乎很低。
在过去，当重新包装非常大的仓库时，malloc失败时，我也改变了core.packedgitwindowsize ， core.packedgitlimit ， core.deltacachesize ， pack.deltacachesize ， pack.window和pack.threads但是，这听起来好像你不需要任何更多的select:)
由于没有直接访问存储库，因此无法执行重新包装，执行浅度克隆，然后逐渐提取，同时增加深度帮助我。
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
希望它仍然可以帮助别人。
我使用以下步骤解决了这个问题。
- 已经从服务器检出到我的本地计算机的存储库（通过SSH使用原始副本）
- 重新打包本地存储库
git repack -a -d --window-memory 10m --max-pack-size 20m - 在服务器上创build一个空的存储库
git init --bare - 推送本地存储库到服务器
- 检查是否可以克隆服务器存储库
这并没有回答这个问题，但有人可能会遇到这样的问题：当pack-objects被某种内存杀手（比如Dreamhost上使用的那个）终止时，重新打包也可能在服务器上失败：
$ git clone project-url project-folder Cloning into project-folder... remote: Counting objects: 6606, done. remote: Compressing objects: 100% (2903/2903), done. error: pack-objects died of signal 9284.51 MiB | 2.15 MiB/s 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
在Dreamhost上，这似乎是由mmap造成的。 重新包装的代码使用mmap将一些文件的内容映射到内存中，由于内存杀手不够聪明，它将mmapped文件作为已用内存进行计数，当试图对大文件进行mmap映射时会终止Git进程。
解决的办法是编译一个自定义的Git二进制文件，closuresmmap支持（ configure NO_MMAP=1 ）。
我使用git版本1.7.0.4，它接受这个命令。 git版本1.6可能不接受这个命令。
尝试用一些随机提交创build一个新的存储库。 然后用这个命令重新包装它。
我有一个私人github.com存储库上的git 2.1.0与Ubuntu 14.10相同的问题。 （企业路由器怀疑！工作在不同的无线networking，除了在工作场所）
* 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
我的解决scheme是，使用SSH混合克隆（我事先设置了ssh键），如下所示：
变为：
git clone git@github.com：USERNAME / REPOSITORYNAME.git
* :(生成一个ssh密钥）
ssh-keygen -t rsa -C“your_email_address_registered_with_github@domain.com”
然后login到github，在设置中，导入ssh密钥，并从〜/ .ssh / id_rsa.pub导入。
