这些对我来说都没用，但使用Heroku的内置工具却奏效了。

heroku git:clone -a myapp

文档在这里:https://devcenter.heroku.com/articles/git-clone-heroku-app

当我运行git拉时，我得到了与下面相同的问题

remote: Counting objects: 149, done.
Connection to git-codecommit.us-east-1.amazonaws.com closed by remote host.
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

然后我检查了git的状态，有很多未提交的更改 我通过提交和推送所有未提交的更改来解决这个问题。

我也遇到过同样的问题。REPO太大，无法通过SSH下载。就像@elin3t推荐的那样，我已经通过HTTP/HTTPS克隆了，并将.git/config中的REMOTE URL更改为使用SSH REPO。

首先，关闭压缩:

git config --global core.compression 0

接下来，让我们做一个部分克隆来截断下来的信息量:

git clone --depth 1 <repo_URI>

当它工作时，进入新目录并检索克隆的其余部分:

git fetch --unshallow 

或者,或者,

git fetch --depth=2147483647

现在，做一个常规的拉:

git pull --all

我认为在1.8版本中msysgit有一个小故障。x版本会加剧这些症状，因此另一种选择是尝试较早版本的git(我认为<= 1.8.3)。

只是在这里添加一个提示，如果你的git克隆命令有一个代理参数，你的代理服务器可能会过早地断开你的http/s请求，因为它自己的配置不允许太大的http响应二进制。仅供参考。

这是令人困惑的，因为Git日志可能会提示任何连接或ssh授权错误，例如:ssh_dispatch_run_fatal: connection to x.x.x.x port yy: message authentication code incorrect，远端意外挂起，早EOF。

服务器端解决方案

让我们在服务器端优化git存储库:

进入我的服务器的git裸库。 调用git gc。 调用git重新打包-A

Eg:

ssh admin@my_server_url.com
sudo su git
cd /home/git/my_repo_name # where my server's bare repository exists.
git gc
git repack -A

现在我能够克隆这个存储库没有错误，例如在客户端:

git clone git@my_server_url.com:my_repo_name

git gc命令可以在git客户端调用，以避免类似的git推送问题。

如果您是Gitlab服务的管理员，请手动触发Housekeeping。它在内部调用git gc或git repack。

客户端解决方案

其他(黑客，仅客户端)解决方案是下载没有历史记录的上一个master:

git clone --single-branch --depth=1 git@my_server_url.com:my_repo_name

有可能不会发生缓冲区溢出。