虽然不是完全相同的设置，但我在Ubuntu 20.04上挂载nfs共享时遇到了这个问题。我还没有找到任何解决方案，所以我分享了我是如何解决的，希望我能帮助到别人。

错误消息是(有时带有/没有警告):

warning: die() called many times. Recursion error or racy threaded death!
fatal: premature end of pack file, 29 bytes missing
fatal: premature end of pack file, 24 bytes missing
fatal: index-pack failed

Git浅克隆，禁用压缩等并没有解决这个问题。

当我用nfsvers=4.2而不是nfsvers=4.0挂载共享时，问题消失了。

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

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

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

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

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

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

最终通过git配置——global core.compression解决

来自BitBucket问题线程:

我试了差不多五次，还是会这样。 然后我尝试使用更好的压缩，它工作! Git配置——global core.compression

从Git文档:

core.compression 整数-1..9，表示默认压缩 的水平。-1是zlib的默认值。 0表示不压缩，1..9是 各种速度/大小的权衡，9是最慢的。 如果设置，这将提供一个 默认为其他压缩变量，如core.looseCompression 和pack.compression。

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

请注意，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.