当我运行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的状态，有很多未提交的更改 我通过提交和推送所有未提交的更改来解决这个问题。

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

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

请注意，Git 2.13.x/2.14(2017年第三季度)确实引发了默认核心。影响git取回的packedGitLimit: 在较大的平台上，默认的package -git限制值已经提高(从8 GiB提高到32 GiB)，以避免“gc”并行运行时“git获取”(可恢复的)失败。

参见David Turner (csusbdt)的commit be4ca29(2017年4月20日)。 帮助:Jeff King (peff)。 (由Junio C Hamano—gitster—在commit d97141b中合并，2017年5月16日)

Increase core.packedGitLimit When core.packedGitLimit is exceeded, git will close packs. If there is a repack operation going on in parallel with a fetch, the fetch might open a pack, and then be forced to close it due to packedGitLimit being hit. The repack could then delete the pack out from under the fetch, causing the fetch to fail. Increase core.packedGitLimit's default value to prevent this. On current 64-bit x86_64 machines, 48 bits of address space are available. It appears that 64-bit ARM machines have no standard amount of address space (that is, it varies by manufacturer), and IA64 and POWER machines have the full 64 bits. So 48 bits is the only limit that we can reasonably care about. We reserve a few bits of the 48-bit address space for the kernel's use (this is not strictly necessary, but it's better to be safe), and use up to the remaining 45. No git repository will be anywhere near this large any time soon, so this should prevent the failure.

确保你的硬盘有足够的剩余空间

网络质量很重要，尽量切换到不同的网络。 帮助我的是把我的互联网连接从维珍媒体(Virgin Media)的高速陆地宽带改为手机上的热点。

在此之前，我尝试了限制克隆大小的公认答案，尝试了在64位和32位版本之间切换，尝试了禁用git文件缓存，没有一个有用。

然后我通过我的手机切换到连接，第一步(git克隆—深度1 <repo_URI>)成功了。切换回我的宽带，但下一步(git fetch -unshallow)也失败了。所以我删除了到目前为止克隆的代码，切换到移动网络，再次尝试默认方式(git clone <repo_URI>)，它成功了，没有任何问题。

就我而言，我只是升级了我的OpenSSL版本。旧版本的OpenSSL有漏洞，也没有可能需要的最新算法。截至今天，命令openssl version显示openssl 1.1.1f 31 Mar 2020。