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.
السؤال المفيد هو: أي وسيط اختاره طلب JGit هذا؟ وليس: هل يحتوي إعداد Git لدي على سطر وسيط؟ نجاح Git الأصلي مقارنة مفيدة، لكنه لا يجيب عن ذلك السؤال الخاص بالتطبيق.