Звичайний 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 — цінне порівняння, але він не відповідає на це питання, специфічне для реалізації.