Git klonēšana darbojas caur starpniekserveri, bet Git LFS neizdodas

Pirms mainīt citādi strādājošu starpniekserveri, izsekojiet Git LFS metadatiem un objektu lejupielādēm atsevišķi no Git klona.

Klons var pabeigt Git objektu pārsūtīšanu, kamēr tā LFS saturs joprojām trūkst. Git glabā norādes failus; LFS klients veic atsevišķus pieprasījumus lielajiem objektiem.

Attiecīgajā darba kopijā ar instalētu Git LFS pārbaudiet tā galapunktu un pēdējo kļūmi:

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

Pārskatiet izvadi lokāli; repozitorija URL un žurnāli var atklāt identificējošu vai autentifikācijas informāciju. Nosakiet pirmo neizdevušos posmu:

  1. Savienojuma izveide ar LFS API.
  2. Batch API lejupielādes darbības iegūšana.
  3. Piekļūšana šīs darbības lejupielādes URL, kas var izmantot citu objektu krātuves resursdatoru un nodrošinātos galvenes.
  4. Objekta pamatteksta pārsūtīšana.

Pārbaudiet repozitorija LFS galapunkta pārrakstīšanu, kā arī faktisko URL. LFS ir sava HTTP implementācija, konfigurācija un mantotā starpniekservera vide. Attiecībā uz Git LFS 3.7.0 izpildiet tā starpniekservera izvēles secību faktiskajam pieprasījuma URL. Parastā Git HTTPS resursdatora sasniegšana neizmēģina katru vēlāko objektu maršrutu. Objektu resursdatora autentifikācijas kļūme arī atšķiras no starpniekservera 407.

Ja plānojat lejupielādes, atsevišķa fetch darbība kontrolētā repozitorijā var atklāt kļūmi bez vēl viena klona:

git -C project lfs fetch

Tas pārsūta objektus; tas nav tikai lasāms iestatījumu vaicājums. Pārliecinieties, ka nepieciešamais saturs pēc tam ir pieejams. Mazs norādes fails, kas palicis daļējā darba kopijā, nav lielais fails, un iepriekš veiksmīga Git komanda nevar apliecināt, ka LFS pārsūtīšana ir pabeigta.

Saistītie raksti