El clon de Git funciona a través del proxy, però Git LFS falla

Un clon pot acabar de transferir els objectes de Git mentre el contingut LFS encara falta. Git emmagatzema fitxers punter; el client LFS fa peticions separades per als objectes grans.

Al checkout afectat amb Git LFS instal·lat, inspeccioneu el seu punt final i l'última fallada:

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

Reviseu la sortida localment; les URL del repositori i els registres poden exposar informació identificativa o d'autenticació. Identifiqueu la primera etapa que ha fallat:

1. Contactar amb l'API de LFS.
2. Obtenir l'acció de descàrrega de la Batch API.
3. Arribar a l'URL de descàrrega d'aquesta acció, que pot utilitzar un amfitrió diferent d'emmagatzematge d'objectes i les capçaleres proporcionades.
4. Transferir el cos de l'objecte.

Comproveu les substitucions del punt final de LFS del repositori i també l'URL real. LFS té la seva pròpia implementació HTTP, configuració i entorn de proxy heretat. Per a Git LFS 3.7.0, seguiu el seu ordre de selecció de proxy per a l'URL real de la petició. Arribar a l'amfitrió HTTPS habitual de Git no recorre totes les rutes d'objectes posteriors. Una fallada d'autenticació de l'amfitrió d'objectes també és diferent d'un proxy 407.

Quan vulgueu les descàrregues, un fetch separat en un repositori controlat pot exposar la fallada sense un altre clon:

git -C project lfs fetch

Això transfereix objectes; no és una consulta de configuració només de lectura. Confirmeu que el contingut necessari està disponible després. Un punter petit que queda en un checkout parcial no és el fitxer gran, i una ordre Git anterior correcta no pot establir que la transferència LFS s'hagi completat.