我在这里有一个非常酷的gitlab设置：
- apache2.2.22-1ubuntu1.4
- gitlab6.5(使用mod_proxy集成到apache)
- uniconv4.3.1(rails Web服务器)
- 2MBit上/下互联网连接
但是，当执行"git克隆"或"git拉取"时，对于大小大于10 Mib的存储库，它会失败。
ubuntu~/Projects/git/myRepo(master|✔) % git pull
Username for 'https://example.org': my.username@mydomain.de
Password for 'https://my.username@mydomain.de@example.org':
remote: Counting objects: 7798, done.
remote: Compressing objects: 100% (4132/4132), done.
fatal: The remote end hung up unexpectedlyiB | 222 KiB/s
fatal: early EOF
fatal: index-pack failed
它似乎能够复制大约8Mib的数据，并且最多运行大约30秒。问题每次都是可重复的，并且一次又一次地显示出相同的故障迹象。
我已阅读：http://jinsucraft.wordpress.com/2013/01/08/when-github-git-clone-fails-with-early-eof-and-index-pack-failed/并尝试过：
git config --global http.postBuffer 524288000
对客户无效。
有人知道是什么原因造成的吗？
此问题的原因可能是超时问题(或类似的限制，例如数据量)：服务器端超时，关闭http连接，导致客户端"早期EOF"错误消息。这样的超时可以在几个地方进行配置(我在这里列出它们，因为其他web服务器可能有类似的设置，所以它们可能会给你一个查找位置的提示)：
- Apache的超时决定了在断开连接之前的绝对静默时间(即没有传输数据)。由于数据是连续接收的，所以这不是问题所在
- Apache mod_proxy的ProxyTimeout是上述Timeout的一个专门设置。同样，由于这不是总请求时间的限制，所以这里没有问题
- Apache可以使用LimitRequestBody来限制POST请求的大小；默认值没有限制，但这可能因您的分发版本的配置而异
- gitlab的Unicorn配置示例建议超时30秒。这是一个绝对超时，例如每一个超过30秒的请求都将被终止
增加Unicorn配置中的超时应该可以解决您的问题。请记住，并行请求的数量也受到Unicorn的限制。克隆大型repo会阻止一个请求，但几乎不会导致CPU负载。如果你的gitlab服务器没有高流量配置文件，你应该考虑增加worker_process的数量。
附带说明：gitlab.yml配置还提供了一个git超时；这个超时限制了git操作，比如计算几个提交的diff。它对克隆/拉取时的超时没有影响。