Git over HTTPS 可以 ls-list 但不能克隆

Question

虽然这是一个常见问题，但这个问题与其他问题特别不同，当我发出 git ls-remote https://myuser@bitbucket.org/myser/repo.git 时，它会要求我输入密码并给出结果：

tomaz:~/ $ git ls-remote https://tcanabrava@bitbucket.org/tcanabrava/randrepo.git
Password: 
1c8cd7266ad19de952db096a0f25ee16dc3cdace        HEAD
1c8cd7266ad19de952db096a0f25ee16dc3cdace        refs/heads/master

但是当我发出 git clone...

tomaz:~/ $ $git clone https://tcanabrava@bitbucket.org/tcanabrava/randrepo.git
Cloning into 'felipao'...
Password: 
error: RPC failed; result=22, HTTP code = 401
fatal: The remote end hung up unexpectedly

而且我已经一遍又一遍地查看了所有谷歌对这个特定错误的答案，但没有什么可以解决它。

1. 我确定地址是正确的，它使用 ls-remote 列出了分支。
2. 已经设置 postBuffer = 52428800
3. 代理很好，它使用 ls-remote 列出了分支
4. 不幸的是，使用 GIT_CURL_VERBOSE=1 运行时间太长，无法在此处发布 =(

Answer 1

使用 Git 2.18（2018 年第二季度），您现在可以更好地控制 Git 使用的 curl。

用于宣传 Git 接受 gzip 编码的 HTTP 客户端代码 从另一边；而是让 cURL 库来做广告 并协商最好的。

见commit eaf6a1b、commit 1a53e69（2018 年 5 月 22 日）Brandon Williams (mbrandonw)。
^{（由 Junio C Hamano -- gitster -- 合并到 commit 13e8be9，2018 年 5 月 30 日）}

remote-curl：接受 curl 支持的所有编码

配置 curl 以接受 curl 支持的所有编码，而不是 只接受 gzip 响应。

这解决了使用 curl 安装时构建的问题 没有“zlib”功能。由于aa90b96（启用 info/refs gzip HTTP 客户端中的解压缩，2012-09-19，Git 1.7.12.3）我们最终还是请求了“gzip”编码，尽管libcurl 无法解码它。
更糟糕的是，我们最终没有得到明确的错误消息来表明这一点 回退到“哑” http，产生令人困惑且难以 调试结果。

因为curl 不做任何检查来验证它是否支持 请求编码，而是设置 curl 选项CURLOPT_ENCODING 一个空字符串，指示 curl 应该发送一个“Accept-Encoding” 标头仅包含 curl 支持的编码。

---

不幸的是，使用 GIT_CURL_VERBOSE=1 运行时间太长，无法在此处发布

在 Git 2.28 之前，无论如何在这里发布 GIT_CURL_VERBOSE or GIT_TRACE_CURL 是不安全的。

使用 Git 2.28（2020 年第三季度），以 GIT_TRACE_CURL 的形式重写对 GIT_CURL_VERBOSE 的支持。

参见Jonathan Tan (jhowtan)commit 7167a62、commit 373e9bd（2020 年 5 月 11 日）。
^{（由 Junio C Hamano -- gitster -- 合并到 commit 0b925a4，2020 年 6 月 9 日）}

http, imap-send：停止使用CURLOPT_VERBOSE

^{签字人：Jonathan Tan}

只要设置了GIT_CURL_VERBOSE，就让Git 表现得如同设置了GIT_TRACE_CURL=1 和GIT_TRACE_CURL_NO_DATA=1，而不是设置CURLOPT_VERBOSE。

这是为了防止无意泄露敏感数据。

特别是，GIT_CURL_VERBOSE 既不会编辑“Authorization”标头，也不会编辑 GIT_REDACT_COOKIES 指定的任何 cookie。

统一跟踪机制还有一个好处，就是对跟踪机制的任何改进都会使GIT_CURL_VERBOSE 和GIT_TRACE_CURL, 的用户都受益，我们不需要记住两次实施任何改进。

---

仍然使用 Git 2.28（2020 年第三季度），在跟踪输出中编辑敏感信息的界面已得到简化。

参见Jonathan Tan (jhowtan) 的commit 827e7d4（2020 年 6 月 5 日）。
^{（由 Junio C Hamano -- gitster -- 合并于 commit b8a5299，2020 年 6 月 22 日）}

http：编辑所有cookie，教GIT_TRACE_REDACT=0

^{签字人：Jonathan Tan}

在跟踪输出中（当GIT_TRACE_CURL 为真时），默认编辑所有 HTTP cookie 的值。
现在，身份验证标头（由于在74c682d3c6 中实现了GIT_TRACE_CURL（“[http.c](https://github.com/git/git/blob/827e7d4da470e8b9b222b2cf3b4a3b7f8c3c671f/http.c）：实现@ 987654377@ 环境变量", 2016-05-24, Git v2.10.0-rc0 -- merge 列在batch #3)) 和 cookie 值（自此提交以来）在这些跟踪中默认被编辑，也允许用户通过环境变量来抑制这些编辑。

由于现在默认编辑所有 cookie 的值，GIT_REDACT_COOKIES（以前允许用户选择单个 cookie 进行编辑）现在无效。

Answer 2

这些是 curl 7.28 错误的确切症状。如果您使用 curl 7.28 将其降级或切换到 SSH 身份验证，直到修复出现。

更多信息：

• http://sourceforge.net/tracker/?func=detail&atid=100976&aid=3577557&group_id=976
• http://curl.haxx.se/mail/tracker-2012-10/0014.html
• https://bugs.archlinux.org/task/32004

Answer 3

我有类似的问题。我不确定有什么帮助，但是：

1. 我将 Curl 降级到 7.25
2. 我用 .netrc 更改了 URL 格式 (http://stackoverflow.com/questions/5796171/git-clone-over-https-401-error-and-not-asking-for-username-or-password/5810821 #5810821)
3. 一切都在 git 1.7.10 下。我从 1.8.0-1 降级（通过 WebDav 拉取和克隆在此版本中不起作用。就使用 1.7 创建的存储库而言。如果有人知道原因，请在评论中写下）。