Git через HTTPS может ls-list, но не может клонировать

Хотя это распространенный вопрос, он особенно отличается от других, когда я запускаю git ls-remote https://[email protected]/myser/repo.git, он запрашивает пароль и дает мне результат:

tomaz:~/ $ git ls-remote https://[email protected]/tcanabrava/randrepo.git
Password: 
1c8cd7266ad19de952db096a0f25ee16dc3cdace        HEAD
1c8cd7266ad19de952db096a0f25ee16dc3cdace        refs/heads/master

но когда я запускаю git clone...

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

И я уже снова и снова просматривал все ответы Google для этой конкретной ошибки, и ничто не могло ее исправить.

  1. Я уверен, что адрес правильный, в нем перечислены ветки, использующие ls-remote.
  2. уже установил postBuffer = 52428800
  3. с прокси все в порядке, список веток отображается с помощью ls-remote
  4. работать с GIT_CURL_VERBOSE=1 слишком долго, чтобы публиковать здесь, к сожалению =(

git bitbucket proxy https curl
person Tomaz Canabrava    schedule 19.10.2012    source источник
comment
Это проблема формата URL-адреса, как в stackoverflow.com/a/5810821/6309? Какую версию git вы используете?   -  person VonC    schedule 20.10.2012
comment
tomaz:Projetos/ $ git git версия 1.8.0   -  person Tomaz Canabrava    schedule 25.10.2012

Ответы (3)


arrow_upward
1
arrow_downward

С Git 2.18 (второй квартал 2018 г.) у вас теперь больше контроля над curl, используемым Git.

Код клиента HTTP, используемый для объявления того, что Git принимает кодировку gzip с другой стороны; вместо этого просто позвольте библиотеке cURL рекламировать и договариваться о лучшем.

См. коммит eaf6a1b, commit 1a53e69 (22 мая 2018 г.), Брэндон Уильямс (mbrandonw).
(Объединено Юнио С. Хамано -- gitster -- в commit 13e8be9, 30 мая 2018 г.)

remote-curl: принимать все кодировки, поддерживаемые curl

Настройте curl так, чтобы он принимал все кодировки, которые поддерживает curl, а не только ответы gzip.

Это устраняет проблему при использовании установки curl, которая собрана без функции zlib. Поскольку aa90b96 (включить распаковку info/refs gzip в HTTP-клиенте, 19 сентября 2012 г. , 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 (3 квартал 2020 г.) поддержка GIT_CURL_VERBOSE переписана с точки зрения GIT_TRACE_CURL.

См. коммит 7167a62, коммит 373e9bd (11 мая 2020 г.), автор Джонатан Тан (jhowtan).
(Объединено Junio ​​C Hamano -- gitster -- в commit 0b925a4, 9 июня 2020 г.)

http, imap-send: прекратите использовать CURLOPT_VERBOSE

Подписано: Джонатан Тан

Всякий раз, когда установлено GIT_CURL_VERBOSE, научите Git вести себя так, как если бы были установлены GIT_TRACE_CURL=1 и GIT_TRACE_CURL_NO_DATA=1, вместо установки CURLOPT_VERBOSE.

Это делается для предотвращения непреднамеренного раскрытия конфиденциальных данных.

В частности, GIT_CURL_VERBOSE не редактирует ни заголовок Authorization, ни файлы cookie, указанные GIT_REDACT_COOKIES.

Унификация механизма отслеживания также имеет будущее преимущество, заключающееся в том, что любые улучшения механизма отслеживания принесут пользу как пользователям GIT_CURL_VERBOSE, так и GIT_TRACE_CURL,, и нам не нужно помнить о необходимости внесения каких-либо улучшений дважды.

По-прежнему в Git 2.28 (3 квартал 2020 г.) интерфейс для редактирования конфиденциальной информации в выводе трассировки был упрощен.

См. commit 827e7d4 (5 июня 2020 г.) от Джонатан Тан (jhowtan).
(объединено Хунио C Хамано -- gitster -- в commit b8a5299, 22 июня 2020 г.)

http: удалить все файлы cookie, научить GIT_TRACE_REDACT=0

Подписано: Джонатан Тан

В выводе трассировки (когда GIT_TRACE_CURL истинно) отредактируйте значения всех файлов cookie HTTP по умолчанию.
Теперь заголовки аутентификации (с момента реализации GIT_TRACE_CURL в 74c682d3c6 ([http.c](https: //github.com/git/git/blob/827e7d4da470e8b9b222b2cf3b4a3b7f8c3c671f/http.c): реализации этой GIT_TRACE_CURL переменной окружения, 2016- 24 05, Git v2.10.0-rc0 – слияние, указанное в batch #3)) и значения файлов cookie (с момента этой фиксации) редактируются по умолчанию в этих трассировках, также разрешить пользователю запретить эти исправления с помощью переменной среды.

Поскольку значения всех файлов cookie теперь редактируются по умолчанию, GIT_REDACT_COOKIES (который ранее позволял пользователям выбирать отдельные файлы cookie для редактирования) теперь не действует.

person VonC    schedule 03.06.2018

arrow_upward
0
arrow_downward

Это точные симптомы ошибки curl 7.28. Если вы используете curl 7.28, понизьте его или переключитесь на аутентификацию SSH, пока не выйдет исправление.

Больше информации:

person John T. Brown    schedule 29.10.2012

arrow_upward
0
arrow_downward

У меня была аналогичная проблема. Не знаю, что помогло, но:

  1. Я понизил Curl до 7.25.
  2. Я изменил формат URL-адреса с помощью .netrc(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. Если кто-то знает, почему, напишите в комментарии).
person shark555    schedule 02.11.2012