Cargo registry downloads کام کرتے ہیں، لیکن Git dependencies ناکام ہوتی ہیں
Cargo registry کے HTTP راستے کو Git sources حاصل کرنے سے الگ کریں اور proxy کا رویہ مختلف ہو تو Git implementation جان بوجھ کر منتخب کریں۔
Cargo proxy تبدیل کرنے سے پہلے ناکام source URL پڑھیں۔ Registry metadata، crate archive اور Git dependency مختلف fetching اور authentication paths استعمال کر سکتے ہیں۔ SSH Git URL کو HTTPS سے مختلف transport arrangement بھی درکار ہے۔
Cargo کی متعلقہ HTTP requests کے لیے route یوں سیٹ کیا جا سکتا ہے:
[http]
proxy = "http://203.0.113.10:8080"Documentation endpoint کو اپنے HTTP proxy سے بدلیں۔ Public proxies استعمال کرنے کی اجازت والے public registry path کے لیے candidates HTTP proxy list میں ہیں۔ اس سے یہ ثابت نہیں ہوتا کہ external Git executable کو وہی configuration ملی۔
اگر ناکام source Git ہو تو Cargo اپنی built-in implementation کے بجائے Git CLI منتخب کر سکتا ہے:
[net]
git-fetch-with-cli = trueCARGO_NET_GIT_FETCH_WITH_CLI=true اسے ایک command کے لیے منتخب کرتا ہے۔ External Git کو اب اپنی proxy configuration اور credentials درکار ہیں۔ اسی launch environment میں اسی Git URL کا موازنہ کریں؛ دوسرے terminal میں کام کرنے والا غیر متعلقہ repository ٹیسٹ نہیں ہے۔
Missing revision، repository permission denial یا SSH host-key error implementation بدلنے کے بعد بھی وہی مسئلہ رہتے ہیں۔ یہ option supported client منتخب کرنے کا طریقہ ہے، عمومی dependency repair نہیں۔
Diagnosis کو project یا command scope میں رکھیں: global Git اور user Cargo settings دوسرے workspaces کو متاثر کر سکتی ہیں۔ Registry URL package data منتخب کرتا ہے، intermediary نہیں۔ Git path کام کرنے کے بعد پوری intended Cargo operation دوبارہ چلائیں، کیونکہ archives، redirects اور build-time downloads دوسرے routes شامل کر سکتے ہیں۔