Aling proxy ang nananalo sa Git LFS 3.7.0?

Sundin ang pagpili ng environment, mga hindi bakanteng Git override na tumutugma sa URL, at mga tuntunin sa paglampas para sa aktwal na URL ng hiling na LFS.

Sa Git LFS 3.7.0, ang hindi bakanteng value ng Git http.proxy na tumutugma sa URL ng hiling ay pumapalit sa proxy na nagmula sa environment. Hindi binubura ng bakanteng value ng Git ang rutang iyon ng environment.

Para sa release na ito, sundin ang pagpili sa ganitong pagkakasunod-sunod:

  1. Basahin ang HTTPS_PROXY at HTTP_PROXY. Ang hindi bakanteng maliit na titik na https_proxy o http_proxy ay pumapalit sa katumbas nitong malaking titik na value.
  2. Para sa HTTPS, unahin ang kandidatong HTTPS at gamitin ang kandidatong HTTP bilang reserba.
  3. Gamitin ang tumutugmang hindi bakanteng value ng Git http.proxy kapalit ng mga kandidatong iyon.
  4. Ilapat ang mga tuntunin sa paglampas sa napiling URL ng hiling. Ang hindi bakanteng no_proxy ay pumapalit sa NO_PROXY.

Kung ang layunin ay direktang pag-access, suriin ang mga namamana na input at ang sinadyang paglampas sa halip na ipagpalagay na binura ang mga ito ng bakanteng entry ng Git.

Gamitin ang aktwal na URL ng LFS para sa paghahambing. Maaaring iba ang mga destinasyon ng API at object kaysa sa Git remote, na nagbabago kung aling setting na nakatali sa URL ang tumutugma.

Itago ang naka-install na bersyon ng LFS kasama ng diagnosis. Gumagamit ang LFS ng sarili nitong Go HTTP transport; hindi ipinapaliwanag ng precedence mula sa libcurl path ng Git ang code ng pagpiling ito.

Kaugnay na mga artikulo