Opphavleg Git fungerer gjennom proxyen, men JGit gjer det ikkje
JGit er ein Java-implementasjon med eigne støtta transportinnstillingar. Ei http.proxy-oppføring i opphavleg Git er ikkje ein universell konfigurasjon for kvar Git-klient.
Det same repositoriet fungerer med git clone i ein terminal og feilar i eit program som brukar JGit. Det er ei samanlikning mellom to implementasjonar, ikkje nødvendigvis mellom ein fungerande og ein øydelagd kopi av same klient.
JGit-konfigurasjonsreferansen seier at proxykonfigurasjon brukar Javas standardmekanismar gjennom java.net.ProxySelector. Ikkje gå ut frå at kvar HTTP-innstilling i opphavleg Git er implementert berre fordi begge klientane forstår ei Git-konfigurasjonsfil.
Identifiser programmet som byggjer inn JGit, versjonen og den valde HTTP-transporten. Vertprogrammet kan tilby innstillingar eller åtferd utover JGit sine sjølvstendige standardverdiar.
Undersøk deretter Java-proxykonfigurasjonen som er synleg for den prosessen. For ein URLConnection-basert HTTP-transport, kontroller JVM-vert- og portegenskapane han brukar. Ein egenskap som blir skriven inn i ein urelatert terminal etter at programmet er starta, kan ikkje omkonfigurere den køyrande JVM-en. Den opphavlege Git-operasjonen til ein IDE og JGit-operasjonen hans kan òg bruke ulike vegar.
Hald proxyautentisering skild frå rutval. Java-proxyegenskapar som angir vert og port implementerer ikkje automatisk eit proxy-passordsystem. Bruk den støtta autentiseringsmekanismen til vertsprogrammet.
Det nyttige spørsmålet er «kva proxy valde denne JGit-førespurnaden?», ikkje «inneheld Git-konfigurasjonen min ei proxylinje?». Ein suksess med opphavleg Git er ei verdifull samanlikning, men ho svarar ikkje på det implementasjonsspesifikke spørsmålet.