مسیریابی پراکسی برای زیرماژول‌های 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های نسبی زیرماژول نیز باید نسبت به remote مناسب ابرپروژه حل شوند، نه نسبت به نشانی وبی که از نام پروژه حدس زده‌اید.

تنظیمات محلی مخزن محدوده دارند

ورودی محلی http.proxy متعلق به مخزنی است که فایل پیکربندی‌اش آن را در بر دارد. فرض نکنید بررسی والد به‌تنهایی همه تنظیمات مؤثر داخل زیرمخزن مقداردهی‌شده را نشان می‌دهد.

برای تعیین موقت پراکسی HTTPS در یک به‌روزرسانی بازگشتی، می‌توانید پیکربندی خط فرمان Git را به همان فراخوانی بدهید:

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

نقطه اتصال نمونه را جایگزین کنید. برای زیرماژول‌های عمومی HTTPS در مسیری که پراکسی عمومی مجاز است، فهرست پراکسی‌های HTTP نشانی‌های پیشنهادی می‌دهد. این کار URLهای SSH را به HTTPS تبدیل نمی‌کند؛ اگر مسیر انتخاب‌شده غیرمنتظره است، پیکربندی اختصاصی‌تر مبتنی بر URL هم باید بررسی شود.

وقتی URL ثبت‌شده عوض شده است

Git هنگام مقداردهی اولیه، پیکربندی زیرماژول را محلی ثبت می‌کند. اگر URL زیرماژول در پروژه تغییر کرده، پیش از نتیجه‌گیری درباره خرابی پراکسی، اعلان فعلی را با مقدار ثبت‌شده محلی مقایسه کنید. عملیات مستند sync، URLهای ثبت‌شده را از اعلان پروژه به‌روز می‌کند؛ خودش تنظیم پراکسی شبکه نیست.

در خطاهای تو‌در‌تو، مسیر دقیق زیرماژول و remote نام‌برده در خطا را یادداشت کنید. عملیات بازگشتی ممکن است با چند میزبان ارتباط بگیرد؛ میزبان داخلی شاید به استثنای اتصال مستقیم نیاز داشته باشد، در حالی که میزبان عمومی از پراکسی استفاده می‌کند.

خطاهای انتقال را از خطاهای مخزن جدا کنید. commit ناموجود، رد دسترسی از سوی مخزن و شکست اتصال به پراکسی دلایل متفاوتی برای همان نتیجه کلی «submodule update failed» هستند.