我在谷歌上搜索过，找到了很多解决方案，但没有一个适合我。
我试图通过连接到LAN网络中的远程服务器从一台机器克隆。
在另一台机器上运行此命令会导致错误。
但是使用git运行相同的克隆命令://192.168.8.5…在服务器上，这是正常的并且成功的。
有什么想法吗?
user@USER ~
$ git clone -v git://192.168.8.5/butterfly025.git
Cloning into 'butterfly025'...
remote: Counting objects: 4846, done.
remote: Compressing objects: 100% (3256/3256), done.
fatal: read error: Invalid argument, 255.05 MiB | 1.35 MiB/s
fatal: early EOF
fatal: index-pack failed
我已经在.gitconfig中添加了这个配置，但也没有帮助。
使用git版本为1.8.5.5.2 .msysgit.0
[core]
compression = -1
正如@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将拉你所有的远程分支现在
请注意，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.
虽然不是完全相同的设置，但我在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挂载共享时，问题消失了。
