Inheemse Git werk deur die proxy, maar JGit nie
JGit is 'n Java-implementering met sy eie ondersteunde vervoerinstellings. 'n Inheemse Git-inskrywing http.proxy is nie 'n universele konfigurasie vir elke Git-kliënt nie.
Dieselfde bewaarplek werk met git clone in 'n terminaal en misluk in 'n toepassing wat JGit gebruik. Dit is 'n vergelyking tussen twee implementerings, nie noodwendig tussen 'n werkende en 'n stukkende kopie van dieselfde kliënt nie.
JGit se konfigurasieverwysing sê die proxy-konfigurasie gebruik Java se standaardmeganismes deur java.net.ProxySelector. Moet nie aanvaar dat elke inheemse Git HTTP-opsie geïmplementeer is bloot omdat albei kliënte 'n Git-konfigurasielêer verstaan nie.
Identifiseer die toepassing wat JGit insluit, sy weergawe en die gekose HTTP-vervoer. Die gasheertoepassing kan instellings of gedrag bied buite JGit se selfstandige verstekke.
Ondersoek dan die Java-proxy-konfigurasie wat vir daardie proses sigbaar is. Vir 'n URLConnection-gebaseerde HTTP-vervoer, kyk na die JVM-gasheer- en poorteienskappe wat dit gebruik. 'n Eienskap wat in 'n onverwante terminaal ingevoer word nadat die toepassing begin het, kan nie die lopende JVM herkonfigureer nie. 'n IDE se inheemse Git-bewerking en sy JGit-bewerking kan ook verskillende paaie gebruik.
Hou proxy-verifikasie apart van roeteseleksie. Java-proxy-eienskappe wat 'n gasheer en poort identifiseer, implementeer nie outomaties 'n proxy-wagwoordskema nie. Gebruik die ondersteunde verifikasiemeganisme van die toepassing wat JGit insluit.
Die nuttige vraag is “watter proxy het hierdie JGit-versoek gekies?” eerder as “bevat my Git-konfigurasie 'n proxy-lyn?”. 'n Sukses met inheemse Git is 'n waardevolle vergelyking, maar dit beantwoord nie daardie implementeringspesifieke vraag nie.