我在谷歌上搜索过,找到了很多解决方案,但没有一个适合我。

我试图通过连接到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

当前回答

我也有同样的问题,我甚至试图直接从网站下载项目作为一个压缩文件,但下载被中断在完全相同的百分比。

这句话像魔法一样解决了我的问题

git config --global core.compression 0

我知道其他答案也提到了这一点,但是这里没有人提到这条线本身就可以解决问题。

希望能有所帮助。

其他回答

我也有同样的问题,我甚至试图直接从网站下载项目作为一个压缩文件,但下载被中断在完全相同的百分比。

这句话像魔法一样解决了我的问题

git config --global core.compression 0

我知道其他答案也提到了这一点,但是这里没有人提到这条线本身就可以解决问题。

希望能有所帮助。

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

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

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

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

只是在这里添加一个提示,如果你的git克隆命令有一个代理参数,你的代理服务器可能会过早地断开你的http/s请求,因为它自己的配置不允许太大的http响应二进制。仅供参考。

首先,关闭压缩:

git config --global core.compression 0

接下来,让我们做一个部分克隆来截断下来的信息量:

git clone --depth 1 <repo_URI>

当它工作时,进入新目录并检索克隆的其余部分:

git fetch --unshallow 

或者,或者,

git fetch --depth=2147483647

现在,做一个常规的拉:

git pull --all

我认为在1.8版本中msysgit有一个小故障。x版本会加剧这些症状,因此另一种选择是尝试较早版本的git(我认为<= 1.8.3)。

如果你在Windows上,你可能想检查git克隆失败的“index-pack”失败?

基本上,在运行git.exe守护进程之后…命令,从控制台窗口中选择一些文本。重试拉/克隆,它现在可能工作了!

更多信息请看这个答案。