रिपॉज़िटरी बनने से पहले रिपॉज़िटरी-स्थानीय 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 नहीं करता।

संबंधित लेख