在我的例子中，问题不在于git配置参数，而是我的存储库中有一个文件超过了系统允许的最大文件大小。我能够检查它试图下载一个大文件，并得到一个“文件大小限制超过”在Debian上。

之后，我编辑了我的/etc/security/limits.conf文件，在它的末尾添加了以下几行:

硬fsize 1000000 软fsize 1000000

要真正“应用”新的限制值，您需要重新登录

首先，关闭压缩:

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)。

正如@ingyhere所说:

浅克隆

首先，关闭压缩:

git config --global core.compression 0

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

git clone --depth 1 <repo_URI>

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

git fetch --unshallow

或者,或者,

git fetch --depth=2147483647

现在，拉一下:

git pull --all

然后解决你本地分支只跟踪主的问题

在您选择的编辑器中打开git配置文件(.git/config)

上面写着:

[remote "origin"]
    url=<git repo url>
    fetch = +refs/heads/master:refs/remotes/origin/master

换线

fetch = +refs/heads/master:refs/remotes/origin/master

to

fetch = +refs/heads/*:refs/remotes/origin/*

做一个git取回和git将拉你所有的远程分支现在

我尝试了这里提出的所有建议，但没有一个奏效。对我们来说，这个问题是不稳定的，而且随着回购的规模越来越大(在Jenkins Windows构建奴隶上)，情况变得越来越糟。

它最终成为git使用的ssh版本。Git被配置为使用某个版本的Open SSH，在用户的.gitconfig文件中通过内核指定。sshCommand变量。把那条线拆了，它就固定了。我相信这是因为Windows现在提供了一个更可靠/兼容的SSH版本，默认使用。

尝试了这里的大部分答案，我得到的错误与PUTTY SSH客户端与所有可能的星座。

一旦我切换到OpenSSH，错误就消失了(删除环境变量GIT_SSH并重新启动git bash)。

我用的是一台新机器和最新的git版本。在许多其他/旧机器上(AWS也是如此)，它在没有任何git配置的情况下使用PUTTY也能正常工作。

这是令人困惑的，因为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

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