Який проксі перемагає в 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 не пояснює цей код вибору.

Схожі статті