Git nativ funcționează prin proxy, dar JGit nu
JGit este o implementare Java cu propriile setări de transport acceptate. O intrare http.proxy în Git nativ nu este o configurație universală pentru fiecare client Git.
Același depozit funcționează cu git clone într-un terminal și eșuează într-o aplicație care folosește JGit. Este o comparație între două implementări, nu neapărat între o copie funcțională și una defectă a aceluiași client.
Referința de configurare a JGit spune că configurația proxy folosește mecanismele standard ale Java prin java.net.ProxySelector. Nu presupuneți că fiecare opțiune HTTP a Git nativ este implementată doar pentru că ambele clienturi înțeleg un fișier de configurare Git.
Identificați aplicația care încorporează JGit, versiunea ei și transportul HTTP ales. Aplicația gazdă poate oferi setări sau comportament dincolo de valorile implicite autonome ale JGit.
Apoi examinați configurația proxy Java vizibilă pentru acel proces. Pentru un transport HTTP bazat pe URLConnection, verificați proprietățile de gazdă și port ale JVM pe care le consumă. O proprietate introdusă într-un terminal nelegat după pornirea aplicației nu poate reconfigura JVM-ul aflat în execuție. Operația Git nativă a unui IDE și operația sa JGit pot folosi și ele căi diferite.
Țineți autentificarea proxy separată de selecția rutei. Proprietățile proxy Java care identifică o gazdă și un port nu implementează automat o schemă de parolă proxy. Folosiți mecanismul de autentificare acceptat al aplicației gazdă.
Întrebarea utilă este „ce proxy a ales această cerere JGit?”, nu „conține configurația mea Git o linie proxy?”. Un succes cu Git nativ este o comparație valoroasă, dar nu răspunde la acea întrebare specifică implementării.