git clone از طریق پروکسی کار می‌کند، اما Git LFS شکست می‌خورد
فراداده‌ها و دانلودهای شیء Git LFS را جدا از git clone ردیابی کنید، پیش از تغییر پروکسی‌ای که در غیر این صورت کار می‌کند.
یک کلون می‌تواند انتقال اشیای Git را کامل کند در حالی که محتوای LFS آن هنوز وجود ندارد. Git فایل‌های اشاره‌گر را ذخیره می‌کند؛ کلاینت LFS درخواست‌های جداگانه‌ای برای اشیای بزرگ ارسال می‌کند.
در نسخهٔ کاری متأثر که Git LFS روی آن نصب است، نقطهٔ پایانی و آخرین شکست آن را بررسی کنید:
git -C project lfs env
git -C project lfs logs lastخروجی را به‌صورت محلی مرور کنید؛ نشانی‌های وب مخزن و گزارش‌ها می‌توانند اطلاعات شناسایی یا احراز هویت را افشا کنند. نخستین مرحلهٔ شکست‌خورده را مشخص کنید:
- تماس با API مربوط به LFS.
- دریافت کنش دانلود Batch API.
- رسیدن به نشانی دانلود آن کنش، که ممکن است از میزبان ذخیره‌سازی شیء متفاوتی و سرآیندهای ارائه‌شده استفاده کند.
- انتقال بدنهٔ شیء.
بازنویسی‌های نقطهٔ پایانی LFS مخزن و همچنین نشانی واقعی را بررسی کنید. LFS پیاده‌سازی HTTP، پیکربندی و محیط پروکسی ارث‌رسیدهٔ خود را دارد. برای Git LFS 3.7.0، ترتیب انتخاب پروکسی آن را برای نشانی واقعی درخواست دنبال کنید. رسیدن به میزبان معمولی HTTPS گیت همهٔ مسیرهای بعدی شیء را آزمون نمی‌کند. شکست احراز هویت در میزبان شیء نیز از خطای 407 پروکسی متمایز است.
وقتی قصد انجام دانلودها را دارید، یک fetch جداگانه در مخزنی کنترل‌شده می‌تواند شکست را بدون کلون دیگری آشکار کند:
git -C project lfs fetchاین اشیا را منتقل می‌کند؛ یک پرس‌وجوی تنظیمات فقط‌خواندنی نیست. پس از آن تأیید کنید که محتوای لازم در دسترس است. یک اشاره‌گر کوچک که در یک نسخهٔ کاری جزئی باقی می‌ماند، همان فایل بزرگ نیست، و یک فرمان موفق پیشین Git نمی‌تواند ثابت کند که انتقال LFS کامل شده است.