将提交推送到 github 时 Git 失败答案

【问题标题】：Git fails when pushing commit to github将提交推送到 github 时 Git 失败
【发布时间】：2011-02-11 18:18:56
【问题描述】：

我将托管在 github 上的 git repo 克隆到我的笔记本电脑上。我能够毫无问题地成功地将几个提交推送到 github。但是，现在我收到以下错误：

Compressing objects: 100% (792/792), done.
error: RPC failed; result=22, HTTP code = 411
Writing objects: 100% (1148/1148), 18.79 MiB | 13.81 MiB/s, done.
Total 1148 (delta 356), reused 944 (delta 214)

从这里它只是挂起，我最后不得不 CTRL + C 回到终端。

【问题讨论】：

为什么会出现 HTTP 错误？你不是通过 SSH 推送到 github 吗？
澄清一下：.git/config 的 origin 部分中的 url 没有说 http，是吗？
@Jefromi 我使用读/写 http 链接克隆了我的私人仓库。
不，它说的是 https。这很奇怪，因为我已经能够在失败之前进行两次推送。

标签： git github rpc

【解决方案1】：

我遇到了同样的问题，并认为它与您尝试推送的 repo 的大小（已编辑或特定文件的大小）有关。

基本上我能够创建新的存储库并将它们推送到 github。但是现有的就不行了。

HTTP 错误代码似乎支持我这是一个“需要长度”错误。所以也许它太大而无法计算或大于最大值。谁知道呢。

编辑

我发现问题可能是大的文件。我有一个更新即使我有，也不会推动成功推动到这一点。提交中只有一个文件但它恰好是 1.6M

所以我添加了以下配置更改
git config http.postBuffer 524288000
允许最大文件大小为 500M 和然后我的推动奏效了。它可能是这是最初的问题在 http 上推送一个大回购协议。

结束编辑

我可以让它工作的方式（在我修改 postBuffer 之前进行编辑）是将我的 repo 压缩，将其复制到可以通过 ssh 执行 git 的机器，然后将其推送到 github。然后，当您尝试从原始服务器进行推/拉时，它应该可以通过 https 工作。（因为它的数据量比原始推送要少得多）。

【讨论】：

也为我工作，虽然我遇到的是 HTTP 501 错误而不是 411。谢谢！
谢谢！这有效，甚至可以加快上传速度。试图将网站推送到新的 Windows Azure 网站，但一直失败。
将这个值设置得非常高有坏处吗？
@snogglethorpe 可能：“传输编码：分块用于避免在本地创建大量包文件”。如果将值设置为很大，则在尝试推送时最终会生成大量包文件。并非所有文件系统都能很好地处理大量文件，并且它们可能无法有效地修剪。你可以在 .git/objects/pack 中看到这些文件。
更改 http.postBuffer 比有害更不必要，但有一个负面影响：将其增加到默认值以上可能会增加较大推送的延迟（因为客户端将将 HTTP 请求缓冲成更大的块）。

【解决方案2】：

我试图推送到我自己托管的 bonobo-git 服务器，但没有意识到 http.postbuffer 意味着项目目录...

所以对于其他困惑的人来说：

为什么？就我而言，我有带有资产的大型 zip 文件，并且还推送了一些 PSD——我猜缓冲区太大了。

如何执行 http.postbuffer：在项目 src 目录中执行该命令，在 .git 文件夹旁边，而不是在服务器上。

请注意，将创建具有该缓冲区大小的大型临时（块）文件。

注意：只需检查您最大的文件，然后设置缓冲区。

【讨论】：

【解决方案3】：

如果这个命令没有帮助

git config http.postBuffer 524288000

尝试将ssh方式改为https

git remote -v
git remote rm origin 
git remote add origin https://github.com/username/project.git

【讨论】：

【解决方案4】：

在这些情况下，如果 https 卡住，您可以尝试 ssh。

您也可以尝试将缓冲区大小增加到天文数字，这样您就不必再担心缓冲区大小了 git config http.postBuffer 100000000

【讨论】：

你记下的 100000000 的数量基本上是 100 MB 这几乎不是天文数字。

【解决方案5】：

推送的问题主要是因为需要推送的文件的大小。我试图推送一些大小仅为 2 mb 的库，然后推送也给出了结果 7 的 RPC 错误。该行是 4 mbps 并且工作正常。随后的一些尝试让我成功了。如果出现此类错误，请等待几分钟并继续尝试。

我还发现，如果 github 已关闭或他们身边的网络不稳定，则会出现一些 RPC 失败。

所以在一段时间后继续尝试是唯一的选择！

【讨论】：

【解决方案6】：

看起来像服务器问题（即“GitHub”问题）。
如果您查看this thread，当git-http-backend 获得损坏的堆时可能会发生这种情况。（并且因为它们just put in place 和smart http support...）
但不管实际原因是什么，也可能与最近的sporadic disruption in one of the GitHub fileserver有关。

您仍然看到此错误消息吗？因为如果你这样做：

检查您的本地 Git 版本（并升级到最新版本）
将此报告为GitHub bug。

注意：Smart HTTP Support 对于我们这些基于身份验证的企业防火墙代理背后的人来说意义重大！

从现在开始，如果您通过http:// url 克隆存储库并且您使用的是 1.6.6 或更高版本的 Git 客户端，Git 将自动使用更新、更好的传输机制。
然而，更令人惊奇的是，您现在可以推送该协议并克隆私有存储库。如果您访问私有存储库，或者您是协作者并想要推送访问，您可以将您的用户名放在 URL 中，当您尝试访问它时，Git 会提示您输入密码。

老客户也将退回到旧的、效率较低的方式，因此不会出现任何问题 - 只是新客户应该工作得更好。

同样，请务必先升级您的 Git 客户端。

【讨论】：

我在 ADSL 无线路由器（French Orange Livebox）后面遇到了类似的问题：无法在github.com 发布我的 SSH 密钥，通过 https 推送卡住...直到我使用备用互联网访问。
当我尝试推送时收到“错误：RPC 失败；结果 = 22，HTTP 代码 = 0”时，智能 HTTP 支持设法让我通过了我们的防火墙代理。
@Boggin 是的，我确认智能 http 通常是代理后面的首选。标准的 http/https 端口（几乎）总是打开的。