Vilken proxy vinner i Git LFS 3.7.0?

Följ miljövalet, icke-tomma URL-matchande Git-överskuggningar och kringgåenderegler för den faktiska LFS-förfrågnings-URL:en.

Ett icke-tomt Git http.proxy-värde som matchar förfrågnings-URL:en åsidosätter proxyn som härleds från miljön i Git LFS 3.7.0. Ett tomt Git-värde rensar inte den miljövägen.

För den här versionen, följ valet i denna ordning:

  1. Läs HTTPS_PROXY och HTTP_PROXY. Ett icke-tomt https_proxy eller http_proxy med små bokstäver ersätter motsvarande värde med stora bokstäver.
  2. För HTTPS, föredra HTTPS-kandidaten och använd HTTP-kandidaten som reserv.
  3. Använd ett matchande icke-tomt Git http.proxy-värde i stället för dessa kandidater.
  4. Tillämpa kringgåenderegler på den valda förfrågnings-URL:en. En icke-tom no_proxy ersätter NO_PROXY.

Om avsikten är direkt åtkomst, granska ärvda indata och det avsedda kringgåendet i stället för att anta att en tom Git-post raderade dem.

Använd den faktiska LFS-URL:en för jämförelsen. API- och objektmål kan skilja sig från Git-fjärrkällan, vilket ändrar vilken URL-bunden inställning som matchar.

Behåll den installerade LFS-versionen tillsammans med diagnosen. LFS använder sin egen Go HTTP-transport; prioritet från Gits libcurl-väg förklarar inte denna valkod.

Relaterade artiklar