Tecnología · GUÍA PRÁCTICA
¿El clone de Git LFS dejó texto de puntero? Prueba la entrega antes de reescribir el historial
Conserva el puntero; separa atributos, endpoint, fetch y checkout, y verifica SHA-256 y tamaño exactos.
Un puntero Git LFS en el working tree no demuestra que el archivo esté corrupto. Registra version, OID SHA-256 y size; el fallo puede estar en atributos, política smudge, endpoint, autenticación, objeto remoto o checkout.
Conserva el clone y el puntero. Prueba toda la cadena hasta los bytes exactos para no convertir un objeto recuperable en una reescritura de historial.
Conserva y clasifica el puntero
Copia archivo, ruta y commit; registra version, oid sha256 y size sin editar.
Si no es válido, detente. Si lo es, no reemplaces, resetees ampliamente ni migres el historial.
Prueba el tracking en este ref
Usa git check-attr y git lfs ls-files para comparar ruta, OID y .gitattributes.
Registra git lfs env, versiones, ref y filtros; un commit correcto puede dejar texto si el filtro se omite.
Separa smudge, fetch y checkout
Revisa GIT_LFS_SKIP_SMUDGE, fetchexclude y CI. Omitir smudge no significa perder el objeto.
Haz fetch del remote/ref exacto, guarda el estado y luego checkout solo de la ruta elegida.
Prueba endpoint, auth y disponibilidad
Registra endpoint y auth. Git puede usar SSH mientras LFS usa HTTPS.
Distingue 401, 403, 404, timeout y exclusión. Reinstalar o resetear no crea un OID ausente.
Materializa poco y verifica
Confirma el OID local y haz checkout solo de la ruta; no empieces con fetch --all.
Compara SHA-256, size y git status. Termina solo cuando cada límite tenga evidencia.
