Git clone პროქსის მეშვეობით მუშაობს, მაგრამ Git LFS ვერ ახერხებს

Git LFS-ის მეტამონაცემებისა და ობიექტების ჩამოტვირთვის კვალი ცალ-ცალკე ადევნეთ Git clone-ს, სანამ შეცვლით პროქსის, რომელიც სხვაგვარად მუშაობს.

clone-მა შეიძლება დაასრულოს Git ობიექტების გადატანა, მაშინ როცა მისი LFS შიგთავსი ჯერ კიდევ აკლია. Git ინახავს მაჩვენებელ ფაილებს; LFS კლიენტი ცალკეულ მოთხოვნებს აგზავნის დიდი ობიექტებისთვის.

დაზარალებულ checkout-ში, სადაც Git LFS დაყენებულია, შეამოწმეთ მისი endpoint და ბოლო შეცდომა:

git -C project lfs env
git -C project lfs logs last

გადახედეთ გამოსავალს ლოკალურად; რეპოზიტორის URL-ები და ლოგები შეიძლება ამჟღავნებდეს იდენტიფიცირებად ან ავთენტიფიკაციის ინფორმაციას. დაადგინეთ პირველი წარუმატებელი ეტაპი:

  1. LFS API-სთან დაკავშირება.
  2. Batch API-ის ჩამოტვირთვის მოქმედების მიღება.
  3. იმ მოქმედების ჩამოტვირთვის URL-ზე მისვლა, რომელიც შეიძლება სხვა ობიექტების საცავის ჰოსტსა და მოწოდებულ header-ებს იყენებდეს.
  4. ობიექტის სხეულის გადატანა.

შეამოწმეთ რეპოზიტორის LFS endpoint-ის გადაფარვები და ასევე რეალური URL. LFS-ს აქვს საკუთარი HTTP იმპლემენტაცია, კონფიგურაცია და მემკვიდრეობით მიღებული პროქსის გარემო. Git LFS 3.7.0-ისთვის მიჰყევით მის პროქსის არჩევის თანმიმდევრობას რეალური მოთხოვნის URL-ისთვის. ჩვეულებრივ Git HTTPS ჰოსტზე მისვლა არ გადის ყველა შემდგომ ობიექტის მარშრუტს. ობიექტის ჰოსტის ავთენტიფიკაციის შეცდომა ასევე განსხვავდება პროქსი 407-ისგან.

როცა ჩამოტვირთვებს აპირებთ, ცალკე fetch კონტროლირებულ რეპოზიტორში შეიძლება გამოავლინოს შეცდომა კიდევ ერთი clone-ის გარეშე:

git -C project lfs fetch

ეს ობიექტებს გადაიტანს; ეს არ არის მხოლოდ წაკითხვადი პარამეტრების მოთხოვნა. ამის შემდეგ დაადასტურეთ, რომ საჭირო შიგთავსი ხელმისაწვდომია. ნაწილობრივ checkout-ში დარჩენილი პატარა მაჩვენებელი არ არის დიდი ფაილი, და ადრინდელი წარმატებული Git ბრძანება ვერ დაადასტურებს, რომ LFS გადატანა დასრულდა.

დაკავშირებული სტატიები