Natuerlike Git wurket troch de proxy, mar JGit net
JGit is in Java-ymplemintaasje mei syn eigen stipe transportynstellingen. In http.proxy-ynset yn natuerlike Git is gjin universele konfiguraasje foar elk Git-klant.
Itselde repository wurket mei git clone yn in terminal en mislearret yn in applikaasje dy't JGit brûkt. Dat is in ferliking tusken twa ymplemintaasjes, net needsaaklikerwize tusken in wurkjende en in stikene kopy fan deselde klant.
De konfiguraasjereferinsje fan JGit seit dat proxykonfiguraasje de standertmeganismen fan Java brûkt fia java.net.ProxySelector. Nim net oan dat elke HTTP-opsje fan natuerlike Git ymplementearre is, allinnich om't beide klanten in Git-konfiguraasjebestân begripe.
Identifisearje de applikaasje dy't JGit ynbêdet, syn ferzje en it keazen HTTP-transport. De hostapplikaasje kin ynstellingen of gedrach biede bûten de selsstannige standertwearden fan JGit.
Undersykje dan de Java-proxykonfiguraasje dy't foar dat proses sichtber is. Foar in HTTP-transport op basis fan URLConnection, kontrolearje de JVM-host- en poarteigenskippen dy't it brûkt. In eigenskip dy't nei it starten fan de applikaasje yn in net-relatearre terminal ynfierd wurdt, kin de rinnende JVM net opnij konfigurearje. De natuerlike Git-operaasje fan in IDE en syn JGit-operaasje kinne ek ferskate paden brûke.
Hâld proxy-autentikaasje skieden fan rûteselksje. Java-proxyeigenskippen dy't in host en poarte oanjaan, ymplementearje net automatysk in proxypasswurdskema. Brûk it stipe autentikaasjemeganisme fan de hostapplikaasje.
De nuttige fraach is “hokker proxy hat dit JGit-fersyk keazen?”, net “befettet myn Git-konfiguraasje in proxyrigel?”. In sukses mei natuerlike Git is in weardefolle ferliking, mar it beantwurdet dy ymplemintaasjespesifike fraach net.