我忘记将更改推送到我已经增量工作了几个月的项目中。这导致 .git 目录非常大(~11 GB)。存储库中的其余文件加起来的成本远低于此。我想将所有提交推送到 github,如果不是一次性的话,那么会逐步推送。因此,我试图将提交逐一推送,以便保持在每次推送的限制范围内。
我的第一次提交(~5.5 GB)推送失败并给出了错误fatal: protocol error: bad line length 819264.11 MiB/s。
我在谷歌搜索时发现了一些类似的消息,但它们都指的是特定的字符错误。我似乎无法理解我遇到的这个错误是什么。
我使用的是 Git 2.22.0 和 macOS 10.15.4;这是通过 HTTPS 推送的,尽管我尝试了 ssh,但遇到了其他问题,所以我切换回来。在此之前我还遇到了另一个问题。我在此之前采取的步骤有更详细的信息。
使用 SSH 的终端输出:
client_loop: send disconnect: Broken pipeB | 1.39 MiB/s
fatal: the remote end hung up unexpectedly
fatal: the remote end hung up unexpectedly
Run Code Online (Sandbox Code Playgroud)
使用 HTTPS 的终端输出:
Enumerating objects: 667, done.
Counting objects: 100% (667/667), done.
Delta compression using up to 8 threads
Compressing objects: 100% (661/661), done.
fatal: protocol error: bad line length 819264.11 MiB/s
error: failed to push some refs to 'https://github.com/USER/REPO.git'
Run Code Online (Sandbox Code Playgroud)
实际的消息是:
fatal: protocol error: bad line length 8192
Run Code Online (Sandbox Code Playgroud)
它只是在不断打印传输速率的持续更新中写入的。最后打印的汇率以 结尾...61.11 MiB/s。
目前尚不清楚是什么原因导致了坏数据包。我建议切换到 ssh,这更有可能解决可解决的问题。但是,您可以设置数据包跟踪选项:
GIT_PACKET_TRACING=1 git push ...
Run Code Online (Sandbox Code Playgroud)
这样你就可以进行逐个数据包的跟踪,然后某人(可能是你)可能会花费大量时间来弄清楚为什么他们发送的行比你的 Git 愿意接收的行更长。
请注意,GitHub不接受大于 100 MB 的文件。请参阅GitHub.com 的存储库大小限制。
| 归档时间: |
|
| 查看次数: |
5499 次 |
| 最近记录: |