Git clone ради преко проксија, али Git LFS не успева

Пратите Git LFS метаподатке и преузимања објеката одвојено од Git clone-а пре него што промените прокси који иначе ради.

Git clone може да заврши пренос Git објеката док LFS садржај још недостаје. Git чува показивачке датотеке; LFS клијент шаље засебне захтеве за велике објекте.

У погођеном checkout-у са инсталираним Git LFS, прегледајте његову крајњу тачку и последњи неуспех:

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

Прегледајте излаз локално; URL-ови и дневници репозиторијума могу открити идентификационе податке или податке за аутентификацију. Идентификујте прву фазу која није успела:

  1. Контактирање LFS API-ја.
  2. Добијање радње преузимања Batch API-ја.
  3. Достизање URL-а за преузимање те радње, који може користити други host за складиштење објеката и достављене заглавља.
  4. Пренос тела објекта.

Проверите замене крајње тачке LFS репозиторијума као и стварни URL. LFS има сопствену HTTP имплементацију, конфигурацију и наслеђено proxy окружење. За Git LFS 3.7.0, пратите његов редослед избора proxy-ја за стварни URL захтева. Достизање уобичајеног Git HTTPS host-а не проверава сваку каснију путању објеката. Неуспех аутентификације на host-у објеката такође се разликује од proxy 407.

Када намеравате преузимања, засебан fetch у контролисаном репозиторијуму може открити неуспех без још једног clone-а:

git -C project lfs fetch

Ово преноси објекте; то није упит подешавања само за читање. Потврдите да је потребан садржај доступан након тога. Мали показивач који остане у делимичном checkout-у није велика датотека, а раније успешна Git команда не може утврдити да је LFS пренос завршен.

Повезани чланци