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

Перегляньте вивід локально; URL-адреси репозиторію та журнали можуть розкрити ідентифікаційну або автентифікаційну інформацію. Визначте перший невдалий етап:

  1. Звернення до LFS API.
  2. Отримання дії завантаження з Batch API.
  3. Доступ до URL-адреси завантаження цієї дії, яка може використовувати інший хост обʼєктного сховища та надані заголовки.
  4. Передавання тіла обʼєкта.

Перевіряйте як перевизначення кінцевої точки LFS у репозиторії, так і фактичну URL-адресу. LFS має власну реалізацію HTTP, конфігурацію та успадковане середовище проксі. Для Git LFS 3.7.0 дотримуйтеся його порядку вибору проксі для фактичної URL-адреси запиту. Доступ до звичайного хоста Git HTTPS не перевіряє кожен наступний маршрут обʼєктів. Помилка автентифікації на хості обʼєктів також відрізняється від проксі 407.

Якщо вам потрібні саме завантаження, окремий fetch у контрольованому репозиторії може виявити помилку без ще одного клонування:

git -C project lfs fetch

Це передає обʼєкти; це не запит налаштувань лише для читання. Підтвердьте, що потрібний вміст після цього доступний. Малий вказівник, що залишився в частковій копії, — не великий файл, і попередня успішна команда Git не доводить, що передавання LFS завершилося.

Схожі статті