একই রিপোজিটরি টার্মিনালে git clone দিয়ে কাজ করে, কিন্তু JGit ব্যবহারকারী অ্যাপ্লিকেশনে ব্যর্থ হয়। এটি দুটি বাস্তবায়নের তুলনা, একই ক্লায়েন্টের কার্যকর ও নষ্ট কপির তুলনা নয়।

JGit-এর কনফিগারেশন রেফারেন্স বলছে প্রক্সি কনফিগারেশন java.net.ProxySelector-এর মাধ্যমে Java-র মানক পদ্ধতি ব্যবহার করে। উভয় ক্লায়েন্ট Git কনফিগারেশন ফাইল বোঝে বলেই নেটিভ Git-এর প্রতিটি HTTP অপশন বাস্তবায়িত হয়েছে ভাববেন না।

JGit অন্তর্ভুক্ত অ্যাপ্লিকেশন, তার সংস্করণ এবং নির্বাচিত HTTP ট্রান্সপোর্ট চিহ্নিত করুন। হোস্ট অ্যাপ্লিকেশন JGit-এর স্বতন্ত্র ডিফল্টের বাইরে সেটিংস বা আচরণ দিতে পারে।

তারপর সেই প্রক্রিয়ার কাছে দৃশ্যমান Java প্রক্সি কনফিগারেশন পরীক্ষা করুন। URLConnection-ভিত্তিক HTTP ট্রান্সপোর্টের জন্য, এটি যে JVM হোস্ট ও পোর্ট বৈশিষ্ট্য ব্যবহার করে তা দেখুন। অ্যাপ্লিকেশন চালু হওয়ার পরে অসম্পর্কিত টার্মিনালে দেওয়া কোনো বৈশিষ্ট্য চলমান JVM পুনরায় কনফিগার করতে পারে না। IDE-র নেটিভ Git অপারেশন এবং তার JGit অপারেশনও ভিন্ন পথ ব্যবহার করতে পারে।

প্রক্সি প্রমাণীকরণকে রুট নির্বাচন থেকে আলাদা রাখুন। হোস্ট ও পোর্ট চিহ্নিত করা Java প্রক্সি বৈশিষ্ট্য স্বয়ংক্রিয়ভাবে প্রক্সি পাসওয়ার্ড স্কিম বাস্তবায়ন করে না। অ্যাপ্লিকেশনের সমর্থিত প্রমাণীকরণ পদ্ধতি ব্যবহার করুন।

উপকারী প্রশ্ন হলো “এই JGit অনুরোধ কোন প্রক্সি বেছে নিয়েছে?”, “আমার Git কনফিগারেশনে প্রক্সি লাইন আছে কি?” নয়। নেটিভ Git-এর সাফল্য মূল্যবান তুলনা, কিন্তু এটি সেই বাস্তবায়ন-নির্দিষ্ট প্রশ্নের উত্তর দেয় না।

সম্পর্কিত নিবন্ধ