Git klonavimas veikia per proxy, bet Git LFS nepavyksta

Prieš keisdami kitaip veikiantį proxy, atskirai išsiaiškinkite Git LFS metaduomenų ir objektų atsisiuntimą nuo Git klonavimo.

Klonavimas gali baigti perkelti Git objektus, nors jo LFS turinys dar trūksta. Git saugo rodyklių failus; LFS klientas atskirai siunčia didelių objektų užklausas.

Paveiktame darbo kataloge, kuriame įdiegtas Git LFS, patikrinkite jo endpoint ir paskutinę klaidą:

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

Peržiūrėkite išvestį vietoje; saugyklos URL ir žurnalai gali atskleisti identifikuojančią arba autentifikavimo informaciją. Nustatykite pirmą nepavykusią stadiją:

  1. Susisiekimas su LFS API.
  2. Batch API atsisiuntimo veiksmo gavimas.
  3. To veiksmo atsisiuntimo URL pasiekimas, kuris gali naudoti kitą objektų saugyklos hostą ir pateiktas antraštes.
  4. Objekto turinio perkėlimas.

Patikrinkite saugyklos LFS endpoint perrašymus ir faktinį URL. LFS turi savo HTTP įgyvendinimą, konfigūraciją ir paveldėtą proxy aplinką. Jei naudojate Git LFS 3.7.0, laikykitės jo proxy pasirinkimo tvarkos faktiniam užklausos URL. Pasiekus įprastą Git HTTPS hostą, tai dar neišbando visų vėlesnių objektų maršrutų. Objektų hosto autentifikavimo klaida taip pat skiriasi nuo proxy 407.

Kai ketinate atsisiųsti, atskiras fetch kontroliuojamoje saugykloje gali atskleisti klaidą be dar vieno klonavimo:

git -C project lfs fetch

Tai perkelia objektus; tai nėra tik skaitoma nustatymų užklausa. Po to patikrinkite, ar reikiamas turinys yra. Mažas rodyklės failas, likęs daliniame darbo kataloge, nėra didelis failas, o anksčiau sėkminga Git komanda negali įrodyti, kad LFS perkėlimas baigtas.

Susiję straipsniai