Inbyggt Git fungerar via proxyn, men JGit gör det inte
JGit är en Java-implementering med egna stödda transportinställningar. En http.proxy-post i inbyggt Git är inte en universell konfiguration för varje Git-klient.
Samma arkiv fungerar med git clone i en terminal och misslyckas i ett program som använder JGit. Det är en jämförelse mellan två implementeringar, inte nödvändigtvis mellan en fungerande och en trasig kopia av samma klient.
JGits konfigurationsreferens säger att proxykonfigurationen använder Javas standardmekanismer via java.net.ProxySelector. Anta inte att varje HTTP-alternativ i inbyggt Git är implementerat bara för att båda klienterna förstår en Git-konfigurationsfil.
Identifiera programmet som bäddar in JGit, dess version och den valda HTTP-transporten. Värdprogrammet kan erbjuda inställningar eller beteende utöver JGits fristående standardvärden.
Granska sedan den Java-proxykonfiguration som är synlig för processen. För en URLConnection-baserad HTTP-transport, kontrollera de JVM-värd- och portegenskaper som den använder. En egenskap som anges i en orelaterad terminal efter att programmet startats kan inte omkonfigurera den körande JVM:en. En IDEs inbyggda Git-operation och dess JGit-operation kan också använda olika vägar.
Håll proxyautentisering åtskild från rutval. Java-proxyegenskaper som anger värd och port implementerar inte automatiskt ett proxylösenordsschema. Använd värdprogrammets stödda autentiseringsmekanism.
Den användbara frågan är ”vilken proxy valde den här JGit-begäran?”, inte ”innehåller min Git-konfiguration en proxylinje?”. En framgång med inbyggt Git är en värdefull jämförelse, men den besvarar inte den implementeringsspecifika frågan.