اصلي Git د پروکسي له لارې کار کوي، خو JGit نه
JGit د Java یو پلي کول دي چې خپل ملاتړ شوي د لېږد تنظیمات لري. په اصلي Git کې د http.proxy ننوتنه د هر Git کلاینټ لپاره نړیواله ترتیبه نه ده.
هماغه زېرمه په ټرمینل کې د git clone سره کار کوي او په هغه اپلیکیشن کې ناکامېږي چې JGit کاروي. دا د دوو پلي کولو ترمنځ پرتله ده، نه لزوماً د یوه کلاینټ د کار کوونکي او خرابې کاپي ترمنځ.
د JGit د ترتیبې مرجع وایي چې د پروکسي ترتیبه د java.net.ProxySelector له لارې د Java معیاري میکانیزمونه کاروي. یوازې ځکه چې دواړه کلاینټونه د Git د ترتیبې فایل پوهېږي، د اصلي Git هر HTTP انتخاب پلي شوی مه ګڼئ.
هغه اپلیکیشن، د هغې نسخه او ټاکل شوی HTTP لېږد وپېژنئ چې JGit پکې ځای پرځای دی. کوربه اپلیکیشن کولای شي د JGit له خپلواکو اصلي ارزښتونو هاخوا تنظیمات یا چلند وړاندې کړي.
بیا هغه Java د پروکسي ترتیبه وګورئ چې دې بهیر ته ښکاري. د URLConnection پر بنسټ HTTP لېږد لپاره، هغه د JVM کوربه او پورټ ځانګړنې وګورئ چې کاروي یې. هغه ځانګړنه چې د اپلیکیشن له پیل وروسته په یوه نامرتبط ټرمینل کې داخلېږي، نشي کولای روان JVM بیا تنظیم کړي. د IDE اصلي Git عملیه او د هغې JGit عملیه هم کولای شي بېلې لارې وکاروي.
د پروکسي تصدیق له لارې ټاکلو جلا وساتئ. هغه Java د پروکسي ځانګړنې چې کوربه او پورټ ښیي، په اتوماتيک ډول د پروکسي پټنوم سکیم نه پلي کوي. د کوربه اپلیکیشن ملاتړ شوی تصدیق میکانیزم وکاروئ.
ګټوره پوښتنه دا ده چې “دې JGit غوښتنې کوم پروکسي وټاکه؟”، نه دا چې “زما د Git ترتیبه کې د پروکسي کرښه ده؟”. د اصلي Git بریالیتوب ارزښتناکه پرتله ده، خو د پلي کولو ځانګړې پوښتنې ته ځواب نه ورکوي.