Native Git funktioniert über den Proxy, JGit nicht
JGit ist eine Java-Implementierung mit eigenen unterstützten Transporteinstellungen. Ein http.proxy-Eintrag in nativem Git ist keine universelle Konfiguration für jeden Git-Client.
Dasselbe Repository funktioniert mit git clone im Terminal und schlägt in einer Anwendung fehl, die JGit verwendet. Das ist ein Vergleich zweier Implementierungen, nicht unbedingt zwischen einer funktionierenden und einer defekten Kopie desselben Clients.
Die JGit-Konfigurationsreferenz besagt, dass die Proxykonfiguration Javas Standardmechanismen über java.net.ProxySelector verwendet. Gehen Sie nicht davon aus, dass jede HTTP-Option von nativem Git implementiert ist, nur weil beide Clients eine Git-Konfigurationsdatei verstehen.
Identifizieren Sie die Anwendung, die JGit einbettet, ihre Version und den gewählten HTTP-Transport. Die Host-Anwendung kann Einstellungen oder Verhalten über JGits eigenständige Standardwerte hinaus bereitstellen.
Prüfen Sie dann die Java-Proxykonfiguration, die für diesen Prozess sichtbar ist. Prüfen Sie bei einem URLConnection-basierten HTTP-Transport die JVM-Host- und Port-Eigenschaften, die er nutzt. Eine Eigenschaft, die nach dem Start der Anwendung in einem anderen Terminal eingegeben wird, kann die laufende JVM nicht neu konfigurieren. Der native Git-Vorgang einer IDE und ihr JGit-Vorgang können ebenfalls unterschiedliche Wege nutzen.
Halten Sie Proxy-Authentifizierung von der Routenwahl getrennt. Java-Proxy-Eigenschaften, die Host und Port angeben, implementieren nicht automatisch ein Proxy-Passwortschema. Verwenden Sie den unterstützten Authentifizierungsmechanismus der Host-Anwendung.
Die sinnvolle Frage ist „Welchen Proxy hat diese JGit-Anfrage gewählt?“ und nicht „Enthält meine Git-Konfiguration eine Proxy-Zeile?“. Ein Erfolg mit nativem Git ist ein wertvoller Vergleich, beantwortet aber nicht diese implementationsspezifische Frage.