Git clone funciona a través do proxy, pero Git LFS falla

Rastrexa os metadatos e as descargas de obxectos de Git LFS por separado do clon de Git antes de cambiar un proxy que doutro xeito funciona.

Un clon pode rematar de transferir os obxectos de Git mentres o seu contido LFS aínda falta. Git almacena ficheiros punteiro; o cliente LFS fai solicitudes separadas para os obxectos grandes.

No checkout afectado co Git LFS instalado, inspecciona o seu endpoint e o último fallo:

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

Revisa a saída localmente; as URL dos repositorios e os rexistros poden expor información identificativa ou de autenticación. Identifica a primeira etapa que fallou:

  1. Contactar coa API de LFS.
  2. Obter a acción de descarga da API Batch.
  3. Chegar á URL de descarga desa acción, que pode usar un host de almacenamento de obxectos distinto e cabeceiras subministradas.
  4. Transferir o corpo do obxecto.

Comproba as substitucións do endpoint LFS do repositorio e tamén a URL real. LFS ten a súa propia implementación HTTP, configuración e contorno de proxy herdado. Para Git LFS 3.7.0, segue a súa orde de selección de proxy para a URL real da solicitude. Chegar ao host HTTPS habitual de Git non exercita todas as rutas de obxectos posteriores. Un fallo de autenticación no host de obxectos tamén é distinto dun proxy 407.

Cando pretendes facer as descargas, un fetch separado nun repositorio controlado pode expor o fallo sen outro clon:

git -C project lfs fetch

Isto transfire obxectos; non é unha consulta de configuración de só lectura. Confirma que o contido necesario está dispoñible despois. Un punteiro pequeno que queda nun checkout parcial non é o ficheiro grande, e un comando Git anterior con éxito non pode establecer que a transferencia LFS se completou.

Artigos relacionados