Git-kloon wurket fia de proxy, mar Git LFS mislearret

Undersykje Git LFS-metadata en objektdownloads apart fan 'e Git-kloon foardat jo in oars wurkjende proxy feroarje.

In kloon kin Git-objekten ferpleatse wylst de LFS-ynhâld noch mist. Git bewarret wizer-bestannen; de LFS-klient docht aparte oanfragen foar de grutte objekten.

Yn 'e oanbelangjende checkout mei Git LFS ynstallearre, besjoch it einpunt en de lêste mislearring:

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

Besjoch de útfier lokaal; repository-URL's en logboeken kinne identifisearjende as autentikaasje-ynformaasje bleatstelle. Identifisearje de earste mislearre stap:

  1. Kontakt opnimme mei de LFS-API.
  2. De download-aksje fan 'e Batch-API bemachtigje.
  3. De download-URL fan dy aksje berikke, dy't in oare object-storage-host en oanlevere headers brûke kin.
  4. It lichem fan it objekt oerdrage.

Kontrolearje oerskriuwings fan it LFS-einpunt fan 'e repository, likegoed as de eigentlike URL. LFS hat syn eigen HTTP-ymplemintaasje, konfiguraasje en erfd proxy-omjouwing. Foar Git LFS 3.7.0, folgje syn proxy-seleksje-oarder foar de eigentlike oanfraach-URL. It berikken fan 'e gewoane Git HTTPS-host testet net alle lettere objektrûtes. In autentikaasjeflater op 'e objekthost is ek oars as proxy 407.

As jo de downloads bedoele, kin in aparte fetch yn in kontrolearre repository de flater bleatstelle sûnder in oare kloon:

git -C project lfs fetch

Dit ferpleatst objekten; it is gjin read-only ynstellingsfraach. Befêstigje dêrnei dat de fereaske ynhâld beskikber is. In lytse wizer dy't efterbliuwt yn in partiele checkout is net de grutte bestân, en in earder slagge Git-opdracht kin net fêststelle dat de LFS-oerdracht foltôge is.

Relatearre artikelen