Звычайны Git працуе праз проксі, а JGit — не
JGit — гэта рэалізацыя на Java з уласнымі падтрыманымі наладамі транспарту. Запіс http.proxy у звычайным Git не з'яўляецца ўніверсальнай наладай для любога кліента Git.
Тое ж сховішча працуе з git clone у тэрмінале і не працуе ў праграме, якая выкарыстоўвае JGit. Гэта параўнанне дзвюх рэалізацый, а не абавязкова працоўнай і зламанай копій аднаго кліента.
Даведка па наладах JGit кажа, што налады проксі выкарыстоўваюць стандартныя механізмы Java праз java.net.ProxySelector. Не мяркуйце, што ўсе параметры HTTP звычайнага Git рэалізаваныя толькі таму, што абодва кліенты разумеюць файл налад Git.
Вызначце праграму, якая ўбудавае JGit, яе версію і абраны транспарт HTTP. Гаспадарчая праграма можа даваць налады або паводзіны звыш аўтаномных значэнняў JGit.
Затым праверце налады проксі Java, бачныя гэтаму працэсу. Для транспарту HTTP на аснове URLConnection праверце уласцівасці хаста і порта JVM, якія ён спажывае. Уласцівасць, уведзеная ў іншым тэрмінале пасля запуску праграмы, не можа пераналадзіць працуючую JVM. Натыўная аперацыя Git у IDE і яе аперацыя JGit таксама могуць выкарыстоўваць розныя шляхі.
Трымайце аўтэнтыфікацыю проксі асобна ад выбару маршруту. Уласцівасці проксі Java, якія вызначаюць хаст і порт, не рэалізуюць схему пароля проксі аўтаматычна. Выкарыстоўвайце падтрыманы механізм аўтэнтыфікацыі ўбудаванай праграмы.
Карыснае пытанне — «які проксі абраў гэты запыт JGit?», а не «ці ёсць у маіх наладах Git радок проксі?». Поспех звычайнага Git — каштоўнае параўнанне, але ён не адказвае на гэтае пытанне, спецыфічнае для рэалізацыі.