Git সাবমডিউলের জন্য প্রক্সি রাউটিং

মূল রিপোজিটরি সফলভাবে ক্লোন হওয়া মানে তার সাবমডিউল পরীক্ষা হওয়া নয়। সাবমডিউল আরেকটি Git রিপোজিটরি; সেটি অন্য হোস্টে থাকতে ও অন্য ট্রান্সপোর্ট ব্যবহার করতে পারে।

ঘোষিত URL পড়ে শুরু করুন:

git -C project config --file .gitmodules --get-regexp '^submodule\..*\.url$'
git -C project submodule status --recursive

HTTPS দিয়ে আনা মূল রিপোজিটরিতে git@host: ব্যবহার করা সাবমডিউল থাকতে পারে। HTTP প্রক্সি সেটিং সেই SSH সংযোগ কনফিগার করে না। আপেক্ষিক সাবমডিউল URL-ও সুপারপ্রজেক্টের উপযুক্ত রিমোটের ভিত্তিতে নির্ণয় করতে হবে, প্রকল্পের নাম থেকে ধরে নেওয়া কোনো ওয়েব ঠিকানার ভিত্তিতে নয়।

রিপোজিটরির নিজস্ব সেটিংয়ের কার্যসীমা আছে

স্থানীয় http.proxy এন্ট্রি যে রিপোজিটরির কনফিগারেশন ফাইলে আছে তারই। শুধু মূলটি দেখলেই ইনিশিয়ালাইজ করা অধীনস্থ রিপোজিটরির সব কার্যকর সেটিং জানা যায়, এমন ধরে নেবেন না।

রিকার্সিভ আপডেটের সময় সাময়িক HTTPS প্রক্সি ওভাররাইড দিতে সেই আহ্বানে Git-এর কমান্ড-লাইন কনফিগারেশন দেওয়া যায়:

git -C project -c http.proxy=http://203.0.113.10:8080 \
  submodule update --init --recursive

উদাহরণ এন্ডপয়েন্ট বদলান। পাবলিক প্রক্সি অনুমোদিত পথে পাবলিক HTTPS সাবমডিউলের জন্য HTTP প্রক্সি তালিকা সম্ভাব্য ঠিকানা দেয়। এতে SSH সাবমডিউল URL HTTPS-এ বদলায় না; নির্বাচিত পথ অপ্রত্যাশিত হলে আরও নির্দিষ্ট URL-ভিত্তিক কনফিগারেশনও দেখা উচিত।

সংরক্ষিত URL বদলে গেলে

Git ইনিশিয়ালাইজেশনের সময় সাবমডিউল কনফিগারেশন স্থানীয়ভাবে নিবন্ধন করে। প্রকল্পে সাবমডিউলের URL বদলে গেলে প্রক্সি অকেজো ভাবার আগে বর্তমান ঘোষণা ও স্থানীয়ভাবে নিবন্ধিত মান তুলনা করুন। নথিভুক্ত sync প্রক্রিয়া প্রকল্পের ঘোষণা থেকে নিবন্ধিত URL হালনাগাদ করে; এটি নিজে নেটওয়ার্ক প্রক্সি সেটিং নয়।

নেস্টেড ব্যর্থতার ক্ষেত্রে ত্রুটিতে বলা সঠিক সাবমডিউল পথ ও রিমোট লিখে রাখুন। রিকার্সিভ প্রক্রিয়া একাধিক হোস্টে যেতে পারে; পাবলিক হোস্ট প্রক্সি ব্যবহার করলেও অভ্যন্তরীণ হোস্টের জন্য সরাসরি সংযোগের ব্যতিক্রম লাগতে পারে।

ট্রান্সপোর্টের ত্রুটি ও রিপোজিটরির ত্রুটি আলাদা রাখুন। অপ্রাপ্য কমিট, রিপোজিটরির প্রবেশ প্রত্যাখ্যান এবং প্রক্সিতে সংযোগ ব্যর্থ হওয়া—একই সাধারণ ‘submodule update failed’ ফলের ভিন্ন কারণ।