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

Una clonación puede terminar de transferir los objetos de Git mientras su contenido LFS sigue faltando. Git guarda archivos puntero; el cliente LFS hace solicitudes separadas para los objetos grandes.

En la copia de trabajo afectada con Git LFS instalado, inspecciona su endpoint y el último fallo:

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

Revisa la salida localmente; las URL del repositorio y los registros pueden exponer información de identificación o autenticación. Identifica la primera etapa que falló:

1. Contactar con la API de LFS.
2. Obtener la acción de descarga de la Batch API.
3. Llegar a la URL de descarga de esa acción, que puede usar un host de almacenamiento de objetos distinto y encabezados proporcionados.
4. Transferir el cuerpo del objeto.

Comprueba las anulaciones del endpoint LFS del repositorio, así como la URL real. LFS tiene su propia implementación HTTP, configuración y entorno de proxy heredado. Para Git LFS 3.7.0, sigue su orden de selección de proxy para la URL de la solicitud real. Llegar al host HTTPS normal de Git no ejercita todas las rutas posteriores de objetos. Un fallo de autenticación en el host de objetos también es distinto de un 407 del proxy.

Cuando quieras hacer las descargas, un fetch separado en un repositorio controlado puede exponer el fallo sin otro clon:

git -C project lfs fetch

Esto transfiere objetos; no es una consulta de configuración de solo lectura. Confirma después que el contenido necesario está disponible. Un puntero pequeño que queda en una copia parcial no es el archivo grande, y un comando Git que tuvo éxito antes no puede demostrar que la transferencia LFS se completó.