ریپوزٹری وجود میں آنے سے پہلے ریپوزٹری کے اندر proxy عجیب لگتا ہے۔ ناکام clone کر کے config میں ترمیم کرنے اور دوبارہ شروع کرنے کی ضرورت نہیں۔

Clone پہلے fetch سے پہلے مقامی سیٹنگ لکھ سکتا ہے:

git clone --config http.proxy=http://proxy.example.net:8080 \
  https://git.example.net/team/project.git project

یہ endpoint مثالیں ہیں۔ اجازت یافتہ عوامی-proxy راستے پر عوامی HTTPS ریپوزٹری کے لیے HTTP proxy فہرست سے HTTP endpoint منتخب کریں۔ Git درج کرتا ہے کہ یہ آپشن نئی ریپوزٹری کے شروع ہونے کے بعد اور اس کی ریموٹ تاریخ fetch ہونے سے پہلے لاگو ہوتا ہے۔ اس لیے یہ proxy سیٹنگ پہلی ڈاؤن لوڈ کو محیط ہو سکتی ہے اور بعد میں نئی ریپوزٹری میں رہ سکتی ہے۔

دو ملتی جلتی کمانڈز مختلف نشان چھوڑتی ہیں

سیٹنگ کو clone شدہ ریپوزٹری میں محفوظ کیے بغیر ایک invocation کو راستہ دینے کے لیے subcommand سے پہلے -c رکھیں:

git -c http.proxy=http://proxy.example.net:8080 \
  clone https://git.example.net/team/project.git project

git clone --config ... اور git -c ... clone قابل تبادلہ config دائرے نہیں ہیں۔ چنیں کہ اس ریپوزٹری میں آئندہ کارروائیاں proxy رکھیں یا نہیں۔

جب یہ انتخاب اہم ہو تو نئی ریپوزٹری کا مقامی config جانچیں۔ دیگر user، system یا URL مخصوص سیٹنگز اب بھی مؤثر پالیسی میں حصہ لے سکتی ہیں۔

راستہ محفوظ کرتے وقت ان مثالوں سے پاس ورڈ دور رکھیں۔ clone کے config آپشن کو دی گئی credential والی قدر مستقل ریپوزٹری سیٹنگ بن سکتی ہے۔

یہ HTTP-transport config ہے، بشمول HTTPS ریموٹ۔ SSH ریموٹ کو اب بھی اپنا SSH proxy راستہ درکار ہے؛ SSH کو port 443 پر منتقل کرنا یہ نہیں کرتا کہ یہ آپشن اسے config کرے۔

متعلقہ مضامین