虽然不是完全相同的设置，但我在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挂载共享时，问题消失了。

当git内存不足时，我得到了这个错误。

释放一些内存(在本例中:让编译作业完成)并再次尝试对我来说是可行的。

在我的情况下，这是一个连接问题。我连接到一个内部wifi网络，在这个网络中，我只能访问有限的资源。这是让git进行取回，但在某个时间它崩溃了。 这意味着它可能是网络连接问题。检查是否一切运行正常:防病毒，防火墙等。

因此，elin3t的答案很重要，因为ssh提高了下载的性能，从而可以避免网络问题

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

虽然不是完全相同的设置，但我在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挂载共享时，问题消失了。

以前的回答建议设置为512m。我想说，有理由认为这在64位架构上是适得其反的。核心文档。packedGitLimit说:

缺省情况下，在32位平台上是256mib，在64位平台上是32tib(实际上是无限的)。这对于所有用户/操作系统都是合理的，除了最大的项目。您可能不需要调整这个值。

如果你想尝试一下，检查你是否设置了它，然后删除设置:

git config --show-origin core.packedGitLimit
git config --unset --global core.packedGitLimit