Git natiboa proxitik pasatzen da, baina JGit ez
JGit Java inplementazioa da, bere garraio-ezarpen onartuekin. Git natiboaren http.proxy sarrera ez da Git bezero guztientzako konfigurazio unibertsala.
Biltegi berak git clone erabiliz funtzionatzen du terminalean, eta JGit erabiltzen duen aplikazio batean huts egiten du. Hori bi inplementazioren arteko alderaketa da, ez nahitaez bezero beraren kopia funtzional eta hondatu baten artekoa.
JGit-en konfigurazio-erreferentziak dio proxy-konfigurazioak Java-ren mekanismo estandarrak erabiltzen dituela java.net.ProxySelector bidez. Ez pentsa Git natiboaren HTTP aukera guztiak inplementatuta daudenik, bi bezeroek Git konfigurazio-fitxategi bat ulertzen dutelako bakarrik.
Identifikatu JGit txertatzen duen aplikazioa, bere bertsioa eta aukeratutako HTTP garraioa. Aplikazio ostalariak JGit-en berezko balio lehenetsiez haragoko ezarpenak edo jokabidea eman ditzake.
Ondoren, aztertu prozesu horrek ikus dezakeen Java proxy konfigurazioa. URLConnection-en oinarritutako HTTP garraiorako, egiaztatu erabiltzen dituen JVM ostalari eta ataka propietateak. Aplikazioa hasi ondoren terminal ez-erronka batean sartutako propietate batek ezin du exekutatzen ari den JVM-a berrikonfiguratu. IDE baten Git eragiketa natiboak eta haren JGit eragiketak bide desberdinak erabil ditzakete.
Eduki proxy autentifikazioa bide-haustearen hautaketaren aparte. Ostalaria eta ataka identifikatzen dituzten Java proxy propietateek ez dute automatikoki proxy pasahitz eskema bat inplementatzen. Erabili aplikazio ostalariaren autentifikazio mekanismo onartua.
Galdera erabilgarria hau da: «zein proxy aukeratu zuen JGit eskaera honek?», eta ez «nire Git konfigurazioak proxy lerro bat dauka?». Git natiboaren arrakasta alderaketa baliotsua da, baina ez dio inplementazioari dagokion galdera horri erantzuten.