Какой прокси побеждает в Git LFS 3.7.0?

Учитывайте выбор из окружения, непустые переопределения Git, совпадающие с URL, и правила обхода для фактического URL запроса LFS.

Непустое значение Git http.proxy, совпадающее с URL запроса, переопределяет прокси, полученный из окружения, в Git LFS 3.7.0. Пустое значение Git не очищает этот путь из окружения.

В этой версии соблюдайте следующий порядок выбора:

  1. Прочитайте HTTPS_PROXY и HTTP_PROXY. Непустое значение в нижнем регистре https_proxy или http_proxy заменяет соответствующее значение в верхнем регистре.
  2. Для HTTPS предпочитайте кандидат HTTPS, а кандидат HTTP используйте как запасной.
  3. Вместо этих кандидатов примените подходящее непустое значение Git http.proxy.
  4. Примените правила обхода к выбранному URL запроса. Непустое no_proxy заменяет NO_PROXY.

Если цель — прямой доступ, проверьте унаследованные входные данные и предполагаемый обход, а не предполагайте, что пустая запись Git их удалила.

Для сравнения используйте фактический URL LFS. Адреса API и объектов могут отличаться от удалённого репозитория Git, из-за чего меняется подходящая настройка, привязанная к URL.

Сохраняйте установленную версию LFS вместе с диагностикой. LFS использует собственный транспорт Go HTTP; приоритет из пути libcurl Git не объясняет этот код выбора.

Похожие статьи