致命错误：早期EOF 致命错误：索引打包失败

Question

我已经Google过并找到了很多解决方案，但都不适用于我。

我正试图通过连接到局域网中的远程服务器来从一台机器克隆。
从另一台机器运行此命令会导致错误。
但在服务器上使用 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.2.msysgit.0

[core]
    compression = -1

- William

---

我在尝试从 VPN 克隆时遇到了这个问题，持续了 2-3 天。在我的情况下，问题出在网络带宽上。我通过在高速网络中进行克隆来解决这个问题。 - Avijit Nagare

我也注意到它与网络有关。 - wonder

我遇到了这个错误，因为我的朋友们不太了解Git，把很多图片推送到仓库里！ =)) - Clite Tailor

我也遇到了同样的错误。我正在使用光纤连接（40Mbps下载速度），而且我的存储库中也没有大文件（比如图片/视频）。尽管如此，仍然出现相同的错误。 - Pawara Siriwardhane

说句实话，我最终通过在共享文件夹中从Linux虚拟机使用git clone来使其在Windows上运行。 - Eric Duminil

Answer 1

首先，关闭压缩：

git config --global core.compression 0

接下来，让我们进行部分克隆来减少传输的信息量：

git clone --depth 1 <repo_URI>

如果成功了，进入新目录并获取剩余的克隆内容：

git fetch --unshallow 

或者，作为替代方案，

git fetch --depth=2147483647

现在，进行常规的拉取操作：

git pull --all

我认为msysgit在1.8.x版本中存在故障，加剧了这些症状，因此另一个选项是尝试使用早期版本的git（<= 1.8.3，我想）。

- ingyhere

---

谢谢，这个方法确实有效。我之前尝试过更改http.postbuffer，但没有成功，不过按照这个回答所述的方法操作后，它很好地解决了我的问题。我没有使用“git fetch --depth=2147483647”这一行，但是我使用了其他的部分。 - Nick Benedict

当我使用较新版本的msysgit时，遇到了这个问题。如果你正在使用msysgit，请尝试使用旧版本（<=1.8.3）。否则，请尝试使用“git fetch --depth 1000”命令（然后是2000等，逐渐增加，直到拉取所有文件为止）。 - ingyhere

@Jose A. -- 还有，请看这个链接：https://dev59.com/nW445IYBdhLWcg3wfKgZ - ingyhere

你好，亲爱的朋友。感谢你提供的出色解决方案。但最后的 git pull --all 没有起作用。这是因为 git clone --depth 1 只会获取一个分支。所以我们需要先编辑 .git/config 文件。 - pjincz

请注意，这不是一个真正的解决方案，因为它会将获取设置为仅针对一个分支，你可能会遇到这种情况：https://dev59.com/-WIj5IYBdhLWcg3wYUCQ - wranvaud

Answer 2

这个错误可能是由于git需要更多的内存而引起的。您可以将以下代码添加到您的全局git配置文件中，该文件位于$USER_HOME下的.gitconfig中，以解决该问题。

[core] 
packedGitLimit = 512m 
packedGitWindowSize = 512m 
[pack] 
deltaCacheSize = 2047m 
packSizeLimit = 2047m 
windowMemory = 2047m

- bhdrkn

---

必须选择此答案。 - Asim Gasimzade

在Windows上，使用Git 2.19，这个问题已得到解决。具体而言，需要添加与pack相关的参数。 - Καrτhικ

可以。但是将所有属性设为8096m。 - Mykola Shorobura

@M-Pixel 应该将其添加到客户端的.gitconfig文件中。 - bhdrkn

这是我在Windows上通过SSH克隆大型代码库时唯一有效的方法。 - david.jade

Answer 3

git config --global core.compression 9 是解决一个 BitBucket 问题的方法。

这个 BitBucket 问题线程中提到：

我试了五次，还是遇到了同样的问题。

然后我尝试使用更好的压缩方式，结果成功了！

git config --global core.compression 9

在 Git 文档中有这样的描述：

core.compression
一个整数 -1..9，表示默认压缩级别。-1 表示 zlib 默认值。
0 表示不压缩，1..9 表示不同的速度/大小权衡，9 最慢。
如果设置了该选项，则会为其他压缩变量（例如 core.looseCompression 和 pack.compression）提供默认值。

- Jacky

---

需要运行 git repack 命令并结合此解决方案，然后它就可以工作了。 - erikH

这个方法可行，我甚至没有尝试其他解决方案，因为这个是最短和最优雅的。应该被接受为答案！ - metablaster

这对我也起作用，通过VPN和公司代理。 --compression 0 不起作用，上面建议的所有 .gitconfig 更改也不起作用。 - Terrence Brannon

可能在这里更改配置参数（以减少传输数据的大小）会起作用，或者可以选择其他方法。 - ingyhere

git config --global core.compression 9 repack 已经生效。 - hafiz031

Answer 4

正如@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

到

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

运行git fetch命令后，git将拉取所有远程分支。

- cmpickle

---

它可以工作，但我将压缩设置为9而不是0，这导致失败。 - metablaster

完美！这应该是答案。 - venugopal

将 fetch = +refs/heads/*:refs/remotes/origin/* 更改为 fetch = +refs/heads/devel:refs/remotes/origin/devel 对我有用。是的，我做了相反的操作，在我们公司，我们使用“devel”作为我们的主分支名称。 - Cezary Drożak

非常感谢，它起作用了！因此，该方法将创建另一个文件夹，在其中克隆和修复存储库。之后，是否有一种方法可以推送我在初始损坏的文件夹中提交但无法推送的工作？ - kingsjester

对我来说for i in `seq 100 100 30000`; do git fetch --depth=$i; done解决了问题（选择最大的seq值，大概是可用提交数量的数量），因为git fetch --unshallow仍然失败。让它运行直到输出只显示：remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0一遍又一遍。这是在香蕉派M2+上使用armbian克隆neovim的唯一方法。 - Daniel Bişar

Answer 5

我遇到了同样的错误，我通过运行这个命令来解决它，在Windows上它有一些内存问题。

git config --global pack.windowsMemory 256m

- Umair Iqbal

---

这个解决方案是今天对我起作用的。我使用的是 Windows 10 64 位操作系统，git 版本为 2.31.1.windows.1。谢谢！ - Pflugs

这对我来说很有效 - undefined

Answer 6

在我的情况下，这非常有帮助：

git clone --depth 1 --branch $BRANCH $URL

这将仅限制结账到所提到的分支，从而加快流程。

希望这能帮到您。

- sMajeed

Answer 7

我的 macOS Big Sur M1 芯片遇到了这个问题，但是没有任何解决方案对我有用。

编辑：对于 M2 芯片也有效。

我通过增加下面的ulimits来解决了它。

ulimit -f 2097152
ulimit -c 2097152
ulimit -n 2097152

运行上述命令只在当前终端会话中有效，因此先运行此命令，然后再克隆存储库。

- Tugay İlik

---

在我尝试安装Homebrew时，这个方法在我的M2 Mac上解决了问题。 - lazd

Answer 8

我尝试了所有这些命令，但都不起作用，但是有效的方法是将git_url从ssh改为http。

如果是clone命令，请执行以下操作：

git clone <your_http_or_https_repo_url> 

如果您要拉取现有的存储库，请使用以下命令：

git remote set-url origin <your_http_or_https_repo_url>

希望这能帮助到某人！

- elin3t

---

这个问题实际上是关于输出中的错误消息，当从连接的存储库同步大块文件时出现问题。你是说改用https而不是ssh克隆就可以完成吗？ - ingyhere

是的！这对我有用，我有一个4GB+的代码库，唯一一个解决方案就是这个！ - elin3t

做法对我有效，谢谢！通过https克隆然后将远程设置回ssh。 - Tuan

我真的很想知道为什么这个有效。是SSH协议中有什么东西无法处理大对象而HTTPS可以吗？这是传输层问题吗？ - bdetweiler

我很久以前就切换到了HTTPS，但今天我注意到发生了中间人攻击，如果我使用VPN，SSH就可以正常工作（无需HTTPS）。 - Top-Master

尝试了这个页面上的所有解决方案，只有这个是有效的。 - timmywil

Answer 9

当git内存耗尽时，我遇到了这个错误。

释放一些内存（在本例中：让编译作业完成）并重试，这对我有用。

- André Laszlo

---

对我来说，可用的内存不多，释放一些内存并重试解决了这个问题。 - Martin Cassidy

Answer 10

在我的情况下，这是一个连接问题。我连接到一个内部wifi网络，在这个网络中我只能访问有限的资源。这导致git可以进行获取操作，但在某个时候它会崩溃。 这意味着可能是网络连接问题。检查一下是否一切都正常运行：防病毒软件、防火墙等等。

因此，elin3t的回答非常重要，因为ssh可以提高下载的性能，从而避免网络问题。

- iberbeu

---

切换到另一个网络，然后它终于工作了。 - YTG