মূল ৰিপ’জিটৰী সফলভাৱে ক্ল’ন হ’লেই তাৰ চাবমডিউল পৰীক্ষা হোৱা নহয়। চাবমডিউল আন এটা Git ৰিপ’জিটৰী; ই বেলেগ হ’ষ্টত থাকিব পাৰে আৰু বেলেগ পৰিবহণ ব্যৱহাৰ কৰিব পাৰে।

প্ৰথমে ঘোষিত URLবোৰ পঢ়ক:

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

HTTPS-ৰে অনা মূল ৰিপ’জিটৰীত git@host: ব্যৱহাৰ কৰা চাবমডিউল থাকিব পাৰে। HTTP প্ৰক্সি ছেটিঙে সেই SSH সংযোগ কনফিগাৰ নকৰে। আপেক্ষিক চাবমডিউল URL মূল প্ৰকল্পৰ উপযুক্ত remote-ৰ ভিত্তিত সমাধান কৰিব লাগে, প্ৰকল্পৰ নামৰ পৰা ধৰি লোৱা কোনো ৱেব ঠিকনাৰ ভিত্তিত নহয়।

ৰিপ’জিটৰী-স্থানীয় ছেটিঙৰ সীমা আছে

স্থানীয় 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 আপডেট কৰে; ই নিজে নেটৱৰ্ক প্ৰক্সি ছেটিং নহয়।

নেষ্টেড বিফলতাৰ ক্ষেত্ৰত ভুলত উল্লেখ কৰা সঠিক চাবমডিউল পথ আৰু remote লিখি ৰাখক। পুনৰাবৃত্ত কাৰ্যই কেইবাটাও হ’ষ্টৰ সৈতে সংযোগ কৰিব পাৰে; পাব্লিক হ’ষ্টে প্ৰক্সি ব্যৱহাৰ কৰিলেও ভিতৰুৱা হ’ষ্টক প্ৰত্যক্ষ সংযোগৰ ব্যতিক্ৰম লাগিব পাৰে।

পৰিবহণৰ ভুল আৰু ৰিপ’জিটৰীৰ ভুল পৃথক ৰাখক। নোপোৱা commit, ৰিপ’জিটৰীয়ে প্ৰৱেশ নাকচ কৰা আৰু প্ৰক্সিলৈ সংযোগ বিফল হোৱা—এইবোৰ একে সাধাৰণ ‘submodule update failed’ ফলৰ বেলেগ বেলেগ কাৰণ।

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