Git clone proksi orqali ishlaydi, lekin Git LFS muvaffaqiyatsiz

Boshqa holatda ishlayotgan proksini o‘zgartirishdan oldin Git LFS metama’lumotlari va obyekt yuklamalarini Git clone’dan alohida kuzating.

Klon Git obyektlarini ko‘chirishni tugatgan bo‘lishi mumkin, LFS mazmuni esa hali yo‘q. Git ko‘rsatkich fayllarini saqlaydi; LFS mijozi katta obyektlar uchun alohida so‘rov yuboradi.

Git LFS o‘rnatilgan ta’sirlangan ish nusxasida uning so‘nggi nuqtasi va oxirgi xatosini tekshiring:

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

Natijani mahalliy ko‘rib chiqing; repozitoriya URL’lari va jurnallar identifikatsiya yoki autentifikatsiya ma’lumotlarini oshkor qilishi mumkin. Birinchi muvaffaqiyatsiz bosqichni aniqlang:

  1. LFS API bilan bog‘lanish.
  2. Batch API’ning yuklab olish amalini olish.
  3. Shu amalning yuklab olish URL’iga yetib borish; u boshqa obyekt saqlash xosti va berilgan sarlavhalardan foydalanishi mumkin.
  4. Obyekt tanasini ko‘chirish.

Repozitoriy LFS so‘nggi nuqta bekor qilishlarini ham, haqiqiy URL’ni ham tekshiring. LFS’ning o‘z HTTP amalga oshirilishi, konfiguratsiyasi va meros qolgan proksi muhiti bor. Git LFS 3.7.0 uchun haqiqiy so‘rov URL’ida uning proksi tanlash tartibiga amal qiling. Oddiy Git HTTPS xostiga yetib borish keyingi har bir obyekt yo‘nalishini sinamaydi. Obyekt xostidagi autentifikatsiya xatosi ham proksi 407dan farq qiladi.

Yuklab olishlarni nazarda tutsangiz, nazorat qilinadigan repozitoriyda alohida fetch yana klon qilmasdan xatoni ko‘rsatishi mumkin:

git -C project lfs fetch

Bu obyektlarni ko‘chiradi; bu faqat o‘qish uchun sozlamalar so‘rovi emas. Keyin kerakli mazmun mavjudligini tasdiqlang. Qismiy ish nusxasida qolgan kichik ko‘rsatkich katta fayl emas va avvalgi muvaffaqiyatli Git buyrug‘i LFS ko‘chirilishi tugaganini isbotlay olmaydi.

O'xshash maqolalar