Git Clone funziona attraverso il proxy, ma Git LFS fallisce

Un clone può completare il trasferimento degli oggetti Git mentre il contenuto LFS è ancora mancante. Git memorizza file puntatore; il client LFS effettua richieste separate per gli oggetti di grandi dimensioni.

Nel checkout interessato con Git LFS installato, esamina il suo endpoint e l'ultimo errore:

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

Esamina l'output localmente; gli URL del repository e i log possono esporre informazioni identificative o di autenticazione. Individua la prima fase non riuscita:

1. Contattare l'API LFS.
2. Ottenere l'azione di download della Batch API.
3. Raggiungere l'URL di download di quell'azione, che può usare un host di archiviazione oggetti diverso e header forniti.
4. Trasferire il corpo dell'oggetto.

Controlla anche le sovrascritture dell'endpoint LFS del repository oltre all'URL effettivo. LFS ha una propria implementazione HTTP, una propria configurazione e un ambiente proxy ereditato. Per Git LFS 3.7.0, segui il suo ordine di selezione del proxy per l'URL effettivo della richiesta. Raggiungere l'host HTTPS Git ordinario non esercita tutte le successive rotte degli oggetti. Un errore di autenticazione dell'host degli oggetti è inoltre distinto da proxy 407.

Quando intendi eseguire i download, un fetch separato in un repository controllato può esporre l'errore senza un altro clone:

git -C project lfs fetch

Questo trasferisce gli oggetti; non è una query di impostazioni in sola lettura. Verifica in seguito che il contenuto richiesto sia disponibile. Un piccolo puntatore rimasto in un checkout parziale non è il file di grandi dimensioni, e un precedente comando Git riuscito non può stabilire che il trasferimento LFS sia stato completato.