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

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

其他回答

对我来说,这很有帮助:

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

这将限制签出到只提到的分支,因此将加快过程。

希望这能有所帮助。

与此相关,仅在没有根访问权限并手动从RPM(使用rpm2cpio)或其他包(.deb, ..)中提取Git到子文件夹时有用。典型的用例:您尝试在公司服务器上使用更新版本的Git而不是过时版本的Git。

如果git克隆失败,导致fatal: index-pack失败,但没有早期的EOF提示,而是提示使用:git index-pack的帮助消息,说明版本不匹配,你需要使用——exec-path参数运行git:

git --exec-path=path/to/subfoldered/git/usr/bin/git clone <repo>

为了让这个过程自动发生,在~/.bashrc中指定:

export GIT_EXEC_PATH=path/to/subfoldered/git/usr/libexec

我在macOS大苏尔M1芯片上遇到了这个问题,没有一个解决方案对我有效。

编辑:作为M2芯片的解决方案,以及。

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

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

运行上面的命令只对当前终端会话有效,所以首先运行这个命令,然后克隆存储库。

在我的例子中,问题不在于git配置参数,而是我的存储库中有一个文件超过了系统允许的最大文件大小。我能够检查它试图下载一个大文件,并得到一个“文件大小限制超过”在Debian上。

之后,我编辑了我的/etc/security/limits.conf文件,在它的末尾添加了以下几行:

硬fsize 1000000 软fsize 1000000

要真正“应用”新的限制值,您需要重新登录

我也有同样的问题。遵循上面的第一步,我能够克隆,但我不能做任何其他事情。不能取、拉或结帐旧树枝。

每个命令运行得比平时慢得多,然后在压缩对象后终止。

I:\dev [master +0 ~6 -0]> git fetch --unshallow
remote: Counting objects: 645483, done.
remote: Compressing objects: 100% (136865/136865), done.

error: RPC failed; result=18, HTTP code = 20082 MiB | 6.26 MiB/s

fatal: early EOF

fatal: The remote end hung up unexpectedly

fatal: index-pack failed

这也发生在你的裁判使用太多内存的时候。修剪记忆为我解决了这个问题。只要给你取回的东西加上一个限制,比如->

git fetch --depth=100

这将获取历史记录中最近100次编辑的文件。 在此之后,您可以以正常速度执行任何命令。