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

შეცვალეთ მაგალითის endpoint. საჯარო HTTPS ქვე-მოდულებისთვის, სადაც საჯარო პროქსი ნებადართულია, მისამართები აიღეთ HTTP პროქსების სიიდან. ეს SSH URL-ებს HTTPS-ად არ გარდაქმნის; მოულოდნელი მარშრუტისას URL-ზე დაფუძნებული უფრო სპეციფიკური პარამეტრიც შეამოწმეთ.

როცა რეგისტრირებული URL შეიცვალა

ინიციალიზაციისას Git ქვე-მოდულის კონფიგურაციას ლოკალურად არეგისტრირებს. URL-ის შეცვლისას მიმდინარე განცხადება ლოკალურ მნიშვნელობას შეადარეთ, სანამ პროქსის დაადანაშაულებთ. sync რეგისტრირებულ URL-ებს პროექტის განცხადებიდან აახლებს; თვითონ ქსელური პროქსის პარამეტრი არ არის.

ჩადგმული შეცდომისას ზუსტი ბილიკი და remote ჩაინიშნეთ. რეკურსიამ შეიძლება რამდენიმე ჰოსტს მიმართოს; შიდა ჰოსტს პირდაპირი გამონაკლისი, საჯაროს კი პროქსი დასჭირდეს.

ტრანსპორტის შეცდომები საცავის შეცდომებისგან გამოყავით. მიუწვდომელი commit, უარყოფილი წვდომა და პროქსის კავშირის ჩავარდნა „submodule update failed“-ის სხვადასხვა მიზეზია.