Обикновеният 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 е ценно сравнение, но не отговаря на този въпрос, специфичен за реализацията.