老实说，我对 git 的内部结构知之甚少。
我已经上演并提交了一个 40mb 的目录，但是当我来推...
$ git push --verbose --progress
Pushing to https://acron0@bitbucket.org/acron0/project.git
Password for 'https://acron0@bitbucket.org':
POST git-receive-pack (chunked)
就这样持续了20分钟。我假设它挂了，但是……我能做些什么来找出原因吗？
这是 Git 中的一个错误；使用 HTTPS 时，它将使用分块编码来上传超过一定大小的内容。那些不起作用。
一个简单的解决方法是告诉 git 在一些可笑的大尺寸值之前不要分块，例如：
git config http.postBuffer 524288000
可能是你的凭据。使用 git+ssh 协议而不是 https。
使用 SourceTree 推送到 BitBucket 我每隔几个月就会收到一次此错误。事实证明，我只需要多等五分钟，它就会自行解决。看起来它已经挂了，诱惑是取消并再试一次，但可能会挂在那里更长时间。我知道这已经得到了回答，但我的提交量可能只有几百 kb，而不是原始发帖人所说的 40mb。
使用 Git 2.13（2017 年第二季度），您将能够设置http.postBuffer一个非常大的数字（即，比ulong某些平台上的更大）。
请参阅David Turner ( )的提交 37ee680（2017 年 4 月 11 日） 。（由Junio C Hamano 合并 -- --在提交 4c01f67中，2017 年 4 月 24 日）csusbdt
gitster
http.postbuffer: 允许全范围的ssize_t值
不幸的是，为了推送一些服务器不支持分块编码的大型存储库，
http postbuffer有时必须超过 2 GB。
在 64 位系统上，这没问题：我们只是 malloc 一个更大的缓冲区。这意味着我们需要使用 CURLOPT_POSTFIELDSIZE_LARGE 来设置缓冲区大小。
因此，Git 2.34（2021 年第四季度）放弃了对 cURL 库的旧版本（7.19.4 之前）的支持：
请参阅Jeff King ( )的提交 644de29、提交 013c7e2、提交 1119a15（2021 年 7 月 30 日） 。
请参阅Ævar Arnfjörð Bjarmason ( ) 的提交 8dda4cb和提交 5db9d38（2021 年 7 月 30 日）。（由Junio C Hamano 合并 -- --在提交 e48a623中，2021 年 8 月 24 日）peffavar
gitster
http: 放弃对 curl < 7.11.1 的支持签字人：Jeff King
签字人：Ævar Arnfjörð Bjarmason
放弃对这个古老版本的 curl 的支持，并通过让我们摆脱一些“#ifdef”来简化代码。
由于我们
CURLOPT_POSTFIELDSIZE在37ee680中使用（“http.postbuffer：允许全范围ssize_t值”，2017-04-11，Git v2.13.0-rc1 -- merge），Git 不会使用 7.11.1 之前的 vanilla curl 构建。
此字段是在 curl 7.11.1 中引入的。我们可以用 more 来解决这些编译问题
#ifdefs，但这不值得。
7.11.1 版于 2004 年 3 月发布，距今已有 17 年之久。
让我们声明它太旧并丢弃任何更早的存在ifdefs。
一个明显的好处是我们将有更少的条件位使代码混乱。此补丁删除了所有
#ifdefs引用旧版本的内容（请注意，curl 的预处理器宏是十六进制的，所以我们正在寻找 070b01，而不是 071101）。
如果您发现该站点是因为 BitBucket 失败并显示该错误消息，请查看此站点的答案：
特别是Nicholas Pickering和Simon Tewsi关于需要将密钥的哪一部分粘贴到 BitBucket 对话框中的评论。