Git-klooni toimii proxyn kautta, mutta Git LFS epäonnistuu

Selvitä Git LFS:n metatiedot ja objektien lataukset erikseen Git-kloonista ennen kuin muutat muuten toimivaa proxya.

Klooni voi saada Git-objektit siirretyksi, vaikka sen LFS-sisältö puuttuu yhä. Git tallentaa osoitintiedostoja; LFS-asiakas tekee erilliset pyynnöt suurille objekteille.

Tarkista kyseisessä työkopiossa, johon Git LFS on asennettu, sen päätepiste ja viimeisin virhe:

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

Tarkastele tulostetta paikallisesti; tietovaraston URL-osoitteet ja lokit voivat paljastaa tunnistavia tietoja tai todennustietoja. Tunnista ensimmäinen epäonnistunut vaihe:

  1. LFS-rajapinnan kutsuminen.
  2. Batch-rajapinnan lataustoiminnon hankkiminen.
  3. Kyseisen toiminnon lataus-URL-osoitteen tavoittaminen; se voi käyttää eri objektitallennusisäntää ja annettuja otsakkeita.
  4. Objektin rungon siirtäminen.

Tarkista tietovaraston LFS-päätepisteen ohitukset sekä todellinen URL-osoite. LFS:llä on oma HTTP-toteutuksensa, oma kokoonpanonsa ja peritty proxy-ympäristönsä. Git LFS 3.7.0:ssa noudata sen proxyn valintajärjestystä todellisen pyyntö-URL:n osalta. Tavallisen Git HTTPS -isännän tavoittaminen ei käy läpi kaikkia myöhempiä objektireittejä. Myös objektien isännän todennusvirhe eroaa proxyn 407-virheestä.

Kun haluat nuo lataukset, erillinen fetch kontrolloidussa tietovarastossa voi paljastaa vian ilman uutta kloonia:

git -C project lfs fetch

Tämä siirtää objekteja; se ei ole pelkkä asetusten lukukysely. Varmista sen jälkeen, että tarvittava sisältö on saatavilla. Osittaiseen työkopioon jäävä pieni osoitin ei ole suuri tiedosto, eikä aiemmin onnistunut Git-komento voi osoittaa, että LFS-siirto on valmistunut.

Aiheeseen liittyvät artikkelit