Welcher Proxy gewinnt in Git LFS 3.7.0?

Verfolgen Sie Umgebungsauswahl, nichtleere URL-passende Git-Überschreibungen und Bypass-Regeln für die tatsächliche LFS-Anfrage-URL.

Ein nichtleerer Git-http.proxy-Wert, der zur Anfrage-URL passt, überschreibt den aus der Umgebung abgeleiteten Proxy in Git LFS 3.7.0. Ein leerer Git-Wert löscht diesen Umgebungspfad nicht.

Befolgen Sie für diese Version die Auswahl in dieser Reihenfolge:

  1. Lesen Sie HTTPS_PROXY und HTTP_PROXY. Ein nichtleeres https_proxy oder http_proxy in Kleinbuchstaben ersetzt den entsprechenden Wert in Großbuchstaben.
  2. Bevorzugen Sie für HTTPS den HTTPS-Kandidaten und verwenden Sie den HTTP-Kandidaten als Rückfall.
  3. Wenden Sie einen passenden nichtleeren Git-http.proxy-Wert anstelle dieser Kandidaten an.
  4. Wenden Sie Bypass-Regeln auf die gewählte Anfrage-URL an. Ein nichtleeres no_proxy ersetzt NO_PROXY.

Wenn direkter Zugriff beabsichtigt ist, prüfen Sie geerbte Eingaben und den beabsichtigten Bypass, statt anzunehmen, ein leerer Git-Eintrag habe sie gelöscht.

Verwenden Sie die tatsächliche LFS-URL für den Vergleich. API- und Objektziele können vom Git-Remote abweichen, was ändert, welche URL-gebundene Einstellung passt.

Halten Sie die installierte LFS-Version bei der Diagnose fest. LFS nutzt seinen eigenen Go-HTTP-Transport; die Priorität aus Gits libcurl-Pfad erklärt diesen Auswahlcode nicht.

Ähnliche Artikel