Git nativo funziona attraverso il proxy, ma JGit no
JGit è un'implementazione Java con le proprie impostazioni di trasporto supportate. Una voce http.proxy di Git nativo non è una configurazione universale per ogni client Git.
Lo stesso repository funziona con git clone in un terminale e fallisce in un'applicazione che usa JGit. È un confronto tra due implementazioni, non necessariamente tra una copia funzionante e una guasta dello stesso client.
Il riferimento di configurazione di JGit afferma che la configurazione del proxy usa i meccanismi standard di Java tramite java.net.ProxySelector. Non dare per scontato che ogni opzione HTTP di Git nativo sia implementata solo perché entrambi i client comprendono un file di configurazione Git.
Identifica l'applicazione che incorpora JGit, la sua versione e il trasporto HTTP scelto. L'applicazione host può fornire impostazioni o comportamenti oltre i valori predefiniti autonomi di JGit.
Poi esamina la configurazione proxy Java visibile a quel processo. Per un trasporto HTTP basato su URLConnection, controlla le proprietà host e porta della JVM che utilizza. Una proprietà inserita in un terminale non correlato dopo l'avvio dell'applicazione non può riconfigurare la JVM in esecuzione. Anche l'operazione Git nativa di un IDE e la sua operazione JGit possono usare percorsi diversi.
Tieni l'autenticazione del proxy separata dalla selezione della rotta. Le proprietà proxy Java che identificano host e porta non implementano automaticamente uno schema di password del proxy. Usa il meccanismo di autenticazione supportato dall'applicazione host.
La domanda utile è «quale proxy ha scelto questa richiesta JGit?», non «la mia configurazione Git contiene una riga proxy?». Un successo con Git nativo è un confronto prezioso, ma non risponde a quella domanda specifica dell'implementazione.