Wil*_*iam 241 git cygwin msysgit
我用Google搜索并找到了许多解决方案,但对我来说都没有用.
我试图通过连接到LAN网络中的远程服务器从一台计算机克隆.
从另一台计算机运行此命令会导致错误.
但是在服务器上使用git://192.168.8.5运行SAME clone命令它没关系并且成功.
有任何想法吗 ？
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
ing*_*ere 452
首先,关闭压缩:
git config --global core.compression 0
接下来,让我们做一个部分克隆来截断下来的信息量:
git clone --depth 1 <repo_URI>
当它工作时,进入新目录并检索克隆的其余部分:
git fetch --unshallow
或者,或者,
git fetch --depth=2147483647
现在,做一个普通的拉:
git pull --all
我认为在1.8.x版本中有一个msysgit的故障加剧了这些症状,所以另一个选择是尝试使用早期版本的git(<= 1.8.3,我认为).
bhd*_*rkn 86
对于git的内存需求可能会发生此错误.您可以将这些行添加到您的全局git配置文件.gitconfig中$USER_HOME,以便解决该问题.
[core]
packedGitLimit = 512m
packedGitWindowSize = 512m
[pack]
deltaCacheSize = 2047m
packSizeLimit = 2047m
windowMemory = 2047m
Uma*_*bal 27
我遇到了同样的错误，在我这边我通过运行此命令解决了，在 Windows 中它有一些内存问题。
git config --global pack.windowsMemory 256m
Tug*_*lik 19
我在使用 macOS Big Sur M1 芯片时遇到了这个问题，但没有一个解决方案对我有用。
编辑：也可作为 M2 芯片的解决方案。
我通过增加下面的 ulimit 解决了这个问题。
ulimit -f 2097152
ulimit -c 2097152
ulimit -n 2097152
运行上面的命令仅对当前终端会话有效，因此首先运行此命令，然后克隆存储库。
Jac*_*cky 17
终于解决了 git config --global core.compression 9
我差不多尝试了五次,但它仍然会发生.
然后我尝试使用更好的压缩,它工作!
git config --global core.compression 9
core.compression
一个整数-1..9,表示默认的压缩级别.-1是zlib的默认值.
0表示没有压缩,1..9是各种速度/大小权衡,9表示最慢.
如果设置,则为其他压缩变量提供默认值,例如core.looseCompression和pack.compression.
cmp*_*kle 12
如@ingyhere所说：
浅克隆
首先，关闭压缩：
git config --global core.compression 0
接下来，让我们进行部分克隆以截断掉下来的信息量：
git clone --depth 1 <repo_URI>
在这种情况下，进入新目录并检索克隆的其余部分：
git fetch --unshallow
或者，
git fetch --depth=2147483647
现在，拉一下：
git pull --all
然后解决你的本地分支只跟踪高手的问题
.git/config在您选择的编辑器中打开您的git配置文件（）
它说：
[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将立即拉出所有远程分支
小智 9
就我而言，这非常有帮助：
git clone --depth 1 --branch $BRANCH $URL
这会将结帐仅限于提及的分支，因此将加快流程。
希望这会有所帮助。
小智 7
设置下面的配置对我不起作用。
[core]
packedGitLimit = 512m
packedGitWindowSize = 512m
[pack]
deltaCacheSize = 2047m
packSizeLimit = 2047m
windowMemory = 2047m
正如之前的评论，这可能是 git 的内存问题。因此，我尝试减少工作线程（从 32 个减少到 8 个）。这样它就不会同时从服务器获取太多数据。然后我还添加“-f”以强制同步其他项目。
-f: Proceed with syncing other projects even if a project fails to sync.
那么现在就可以正常工作了。
repo sync -f -j8
这很令人困惑，因为 Git 日志可能会建议任何连接或 ssh 授权错误，例如：ssh_dispatch_run_fatal: Connection to x.x.x.x port yy: message authentication code incorrect, the remote end hung up unexpectedly, early EOF。
服务器端解决方案
让我们在服务器端优化 git 存储库：
git gc。git repack -A例如：
ssh admin@my_server_url.com
sudo su git
cd /home/git/my_repo_name # where my server's bare repository exists.
git gc
git repack -A
现在我可以毫无错误地克隆这个存储库，例如在客户端：
git clone git@my_server_url.com:my_repo_name
git gc可以在 git 客户端调用该命令以避免类似git push问题。
如果您是 Gitlab 服务的管理员 - 手动触发Housekeeping。它在内部调用git gc或git repack.
客户端解决方案
其他（黑客，仅限客户端）解决方案是下载没有历史记录的最后一个主版本：
git clone --single-branch --depth=1 git@my_server_url.com:my_repo_name
有可能不会发生缓冲区溢出。
就我而言，这是一个连接问题。我连接到内部 wifi 网络，在该网络中我对资源的访问受到限制。那是让 git 进行获取，但在某个时间它崩溃了。这意味着它可能是网络连接问题。检查一切是否正常运行：防病毒、防火墙等。
因此，elin3t 的回答很重要，因为 ssh 提高了下载的性能，从而可以避免网络问题
请注意，Git 2.13.x/2.14（2017 年第 3 季度）确实提高了默认值，core.packedGitLimit这会影响git fetch：
在较大平台上提高了默认的 Packed-git 限制值（从 8 GiB 到 32 GiBgit fetch ），以将“ ”从（可恢复的）故障中拯救出来。而“ gc”则并行运行。
请参阅David Turner提交的 be4ca29（2017 年 4 月 20 日） ( )。
帮助者：杰夫·金 (Jeff King )。（由Junio C Hamano 合并 -- --在提交 d97141b中，2017 年 5 月 16 日）csusbdtpeff
gitster
增加
core.packedGitLimit当
core.packedGitLimit超过时，git 将关闭包。
如果重新打包操作与获取并行进行，则获取可能会打开一个包，然后由于达到了 PackedGitLimit 而被迫关闭它。
然后，重新打包可能会从提取下删除该包，从而导致提取失败。增加
core.packedGitLimit的默认值可以防止这种情况发生。在当前的 64 位 x86_64 机器上，有 48 位的地址空间可用。
64 位 ARM 机器似乎没有标准的地址空间量（即，它因制造商而异），而 IA64 和 POWER 机器则具有完整的 64 位。
所以 48 位是我们可以合理关心的唯一限制。我们保留 48 位地址空间中的一些位供内核使用（这不是绝对必要的，但最好是安全起见），并使用剩余的 45 位。
任何时候都不会有这么大的 git 存储库很快，所以这应该可以防止失败。
我也面临这个问题，这是我的解决方案：
git fetch --refetch
来自git-fetch帮助：
此选项不会与服务器协商以避免传输本地已存在的提交和关联对象，而是会像新克隆一样获取所有对象
我尝试了所有这些命令，但没有一个对我有用，但是有效的方法是将git_url更改为http而不是ssh
如果是clone命令，请执行以下操作：
git clone <your_http_or_https_repo_url>
否则，如果您要使用现有存储库，请执行以下操作
git remote set-url origin <your_http_or_https_repo_url>
希望这对某人有所帮助！
之前的答案建议设置为 512m。我想说，有理由认为这在 64 位架构上会适得其反。core.packedGitLimit 的文档说：
32 位平台上的默认值为 256 MiB，64 位平台上的默认值为 32 TiB（实际上无限制）。这对于所有用户/操作系统来说都是合理的，除了最大的项目。您可能不需要调整该值。
如果您想尝试一下，请检查是否已设置，然后删除该设置：
git config --show-origin core.packedGitLimit
git config --unset --global core.packedGitLimit
编辑：这里有一个衔尾蛇时刻，应该提到的是，这与@ amirreza-moeini-yegane的解决方案相结合，今天为我解决了这个问题。
git config --global core.compression 0
| 归档时间： |
|
| 查看次数： |
266122 次 |
| 最近记录： |