Git natif fonctionne via le proxy, JGit non
JGit est une implémentation Java avec ses propres paramètres de transport pris en charge. Une entrée http.proxy de Git natif n'est pas une configuration universelle pour tous les clients Git.
Le même dépôt fonctionne avec git clone dans un terminal et échoue dans une application utilisant JGit. C'est une comparaison entre deux implémentations, pas nécessairement entre une copie fonctionnelle et une copie cassée du même client.
La référence de configuration de JGit indique que la configuration du proxy utilise les mécanismes standard de Java via java.net.ProxySelector. Ne partez pas du principe que toutes les options HTTP de Git natif sont implémentées simplement parce que les deux clients comprennent un fichier de configuration Git.
Identifiez l'application qui intègre JGit, sa version et le transport HTTP choisi. L'application hôte peut fournir des paramètres ou un comportement au-delà des valeurs par défaut autonomes de JGit.
Examinez ensuite la configuration proxy Java visible par ce processus. Pour un transport HTTP basé sur URLConnection, vérifiez les propriétés d'hôte et de port de la JVM qu'il utilise. Une propriété saisie dans un terminal sans rapport après le démarrage de l'application ne peut pas reconfigurer la JVM en cours d'exécution. L'opération Git native d'un IDE et son opération JGit peuvent aussi emprunter des chemins différents.
Gardez l'authentification du proxy distincte de la sélection de route. Les propriétés proxy Java qui identifient un hôte et un port n'implémentent pas automatiquement un schéma de mot de passe proxy. Utilisez le mécanisme d'authentification pris en charge par l'application hôte.
La question utile est « quel proxy cette requête JGit a-t-elle choisi ? », et non « ma configuration Git contient-elle une ligne proxy ? ». Un succès avec Git natif est une comparaison précieuse, mais il ne répond pas à cette question propre à l'implémentation.