2

虽然这是一个常见问题，但这个问题与其他问题不同，当我发出 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 运行时间太长，无法在此处发布 =(
4

3 回答 3

1

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

用于宣传 Git 接受来自另一端的 gzip 编码的 HTTP 客户端代码；相反，只需让 cURL 库宣传和协商最好的库。

请参阅提交 eaf6a1b，提交 1a53e69（2018 年 5 月 22 日），作者为Brandon Williams ( mbrandonw)。
（由Junio C Hamano 合并gitster——在提交 13e8be9中，2018 年 5 月 30 日）

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

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

zlib这解决了使用没有“ ”功能构建的 curl 安装时的问题。由于aa90b96（在 HTTP 客户端中启用 info/refs gzip 解压缩，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或GIT_TRACE_CURL.

使用 Git 2.28（2020 年第三季度），重写GIT_CURL_VERBOSE对GIT_TRACE_CURL.

请参阅Jonathan Tan ( ) 的提交 7167a62和提交 373e9bd（2020 年 5 月 11 日）。（由Junio C Hamano 合并 -- --在提交 0b925a4中，2020 年 6 月 9 日）jhowtan
gitster

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.

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

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

请参阅Jonathan Tan ( ) 的提交 827e7d4（2020 年 6 月 5 日）。（由Junio C Hamano 合并 -- --在提交 b8a5299中，2020 年 6 月 22 日）jhowtan
gitster

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

签字人：Jonathan Tan

在跟踪输出中（当GIT_TRACE_CURL为真时），默认编辑所有 HTTP cookie 的值。
现在，auth 标头（由于GIT_TRACE_CURL在74c682d3c6中实现（“ [http.c ](https://github.com/git/git/blob/827e7d4da470e8b9b222b2cf3b4a3b7f8c3c671f/http.c）：实现GIT_TRACE_CURL环境变量”，2016-05-24，Git v2 .10.0-rc0 --合并在批次 #3中列出））和 cookie 值（自此提交以来）在这些跟踪中默认编辑，还允许用户通过环境变量禁止这些编辑。

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

于 2018-06-03T23:04:31.727 回答
0

These are exact symptomps of a curl 7.28 bug. If you are using curl 7.28 downgrade it or switch to SSH auth until the fix comes out.

More info:

于 2012-10-29T07:45:59.343 回答
0

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

  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 创建的存储库而言。如果有人知道原因，请在评论中写下）。
于 2012-11-02T18:37:40.083 回答