Gumagana ang parehong repository na may git clone sa terminal at nabibigo sa isang application na gumagamit ng JGit. Iyon ay paghahambing sa pagitan ng dalawang implementasyon, hindi kinakailangan sa pagitan ng gumagana at sirang kopya ng parehong kliyente.

Sinasabi ng reference ng configuration ng JGit na ang configuration ng proxy ay gumagamit ng mga karaniwang mekanismo ng Java sa pamamagitan ng java.net.ProxySelector. Huwag ipagpalagay na ang bawat opsyon sa HTTP ng native na Git ay naipatupad dahil lamang nauunawaan ng dalawang kliyente ang isang configuration file ng Git.

Tukuyin ang application na naglalagay ng JGit, ang bersyon nito, at ang napiling transport na HTTP. Ang host application ay maaaring magbigay ng mga setting o pag-uugali na lampas sa mga standalone na default ng JGit.

Pagkatapos, suriin ang configuration ng proxy ng Java na nakikita ng prosesong iyon. Para sa transport na HTTP na nakabatay sa URLConnection, tingnan ang mga property ng host at port ng JVM na ginagamit nito. Ang isang property na inilagay sa isang walang kaugnayang terminal pagkatapos magsimula ang application ay hindi maaaring muling i-configure ang tumatakbong JVM. Ang native na operasyon ng Git ng isang IDE at ang operasyon nitong JGit ay maaari ring gumamit ng magkaibang mga landas.

Ihiwalay ang authentication ng proxy sa pagpili ng ruta. Ang mga property ng proxy ng Java na nagtutukoy ng host at port ay hindi awtomatikong nagpapatupad ng scheme ng password ng proxy. Gamitin ang sinusuportahang mekanismo ng authentication ng host application.

Ang kapaki-pakinabang na tanong ay “aling proxy ang pinili ng kahilingang JGit na ito?”, hindi “may linya ba ng proxy ang configuration ko ng Git?”. Ang tagumpay sa native na Git ay isang mahalagang paghahambing, ngunit hindi nito sinasagot ang tanong na iyon na partikular sa implementasyon.

Kaugnay na mga artikulo