Git clone работи през прокси, но Git LFS се проваля

Проследете метаданните на Git LFS и изтеглянето на обекти отделно от Git 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 адреса за изтегляне на това действие, който може да използва различен хост за обектно хранилище и предоставени заглавки.
  4. Прехвърляне на тялото на обекта.

Проверете заместванията на LFS endpoint в хранилището, както и действителния URL. LFS има собствена HTTP реализация, конфигурация и наследена прокси среда. За Git LFS 3.7.0 следвайте неговия ред на избор на прокси за действителния URL на заявката. Достигането до обичайния Git HTTPS хост не проверява всеки следващ маршрут до обекти. Провалът при удостоверяване на хоста на обектите също е различен от прокси 407.

Когато възнамерявате да извършите изтеглянията, отделно fetch в контролирано хранилище може да покаже провала без ново клониране:

git -C project lfs fetch

Това прехвърля обекти; това не е заявка за настройки само за четене. След това потвърдете, че необходимото съдържание е налично. Малък указател, останал в частично checkout, не е големият файл и по-ранна успешна Git команда не може да докаже, че прехвърлянето на LFS е завършило.

Подобни статии