Natywny Git działa przez proxy, ale JGit nie
JGit to implementacja w Javie z własnymi obsługiwanymi ustawieniami transportu. Wpis http.proxy w natywnym Gicie nie jest uniwersalną konfiguracją dla każdego klienta Git.
To samo repozytorium działa z git clone w terminalu, a zawodzi w aplikacji korzystającej z JGit. To porównanie dwóch implementacji, niekoniecznie działającej i zepsutej kopii tego samego klienta.
Dokumentacja konfiguracji JGit mówi, że konfiguracja proxy korzysta ze standardowych mechanizmów Javy przez java.net.ProxySelector. Nie zakładaj, że każda opcja HTTP natywnego Gita jest zaimplementowana tylko dlatego, że oba klienty rozumieją plik konfiguracyjny Git.
Zidentyfikuj aplikację osadzającą JGit, jej wersję i wybrany transport HTTP. Aplikacja hostująca może udostępniać ustawienia lub zachowanie wykraczające poza samodzielne wartości domyślne JGit.
Następnie sprawdź konfigurację proxy Javy widoczną dla tego procesu. W przypadku transportu HTTP opartego na URLConnection sprawdź właściwości hosta i portu JVM, których używa. Właściwość wpisana w niepowiązanym terminalu po uruchomieniu aplikacji nie może przekonfigurować działającej JVM. Natywna operacja Git w IDE i jej operacja JGit również mogą używać różnych ścieżek.
Trzymaj uwierzytelnianie proxy oddzielnie od wyboru trasy. Właściwości proxy Javy określające hosta i port nie implementują automatycznie schematu hasła proxy. Użyj obsługiwanego mechanizmu uwierzytelniania aplikacji hostującej.
Użytecznym pytaniem jest „który proxy wybrało to żądanie JGit?”, a nie „czy moja konfiguracja Git zawiera wiersz proxy?”. Sukces natywnego Gita jest cennym porównaniem, ale nie odpowiada na to pytanie specyficzne dla implementacji.