Git клонирањето работи преку прокси, но Git LFS не успева

Следете ги метаподатоците и преземањата на објекти на Git LFS одделно од Git клонот пред да менувате прокси што инаку работи.

Клонот може да го заврши преносот на 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 е завршен.

Поврзани статии