Tecnología · GUÍA PRÁCTICA
¿Git dice “object file is empty”? Conserva el OID antes de borrar nada
Un loose object de cero bytes es evidencia del repositorio, no basura. Detén las escrituras, conserva el OID completo y .git, inventaría el daño y recupera el objeto exacto o rescata el trabajo local.
“object file … is empty” significa que existe una ruta de objeto suelto, pero Git no puede leer un objeto válido. Trata el OID completo y el repositorio como evidencia; no empieces borrando vacíos, con reset --hard ni sustituyendo todo .git.
Detén las escrituras, copia el árbol de trabajo y .git en otro almacenamiento, registra el OID exacto y haz un inventario de solo lectura. La recuperación depende del tipo y alcance del objeto y de si existe una copia fiable en remoto, clon independiente, alternates o copia de seguridad.
Detén las escrituras y conserva pruebas
Detén editores, integraciones Git del IDE, sincronización y mantenimiento. Guarda el error completo, ruta, OID, status disponible y síntomas de caída, energía, disco lleno o sistema de archivos.
Copia el árbol y .git a otro almacenamiento. Conserva la ruta de cero bytes bajo su OID completo. En un repositorio bare del servidor, detén escrituras y usa el proceso de mantenimiento y copias de la plataforma.
Haz inventario antes de reparar
Ejecuta git fsck --full en una copia conservada; guarda también --no-reflogs si necesitas comparar sin reflogs como raíces. Separa missing, bad, dangling y unreachable.
Revisa alternates, packs, refs y reflogs, y determina si falla uno o varios objetos. No ejecutes gc, prune, reset --hard ni borrado masivo mientras ignores el límite del daño.
Clasifica el OID y busca una copia fiable
Usa los enlaces de fsck para saber si es blob, tree, commit o tag. En un blob, el tree que lo referencia y git ls-tree pueden revelar la ruta; commits y trees son más difíciles de reconstruir.
Comprueba el OID completo en un clon independiente, remoto, bundle, backup y alternate. Un fetch normal solo sirve si el remoto posee el objeto y ya conservaste la historia solo local.
Elige la recuperación menos destructiva
Si existe el objeto exacto en una fuente fiable, restáuralo mediante una ruta consciente de Git o desde backup, verifica el OID y repite fsck. No reemplaces todo .git con otro repositorio.
Si puedes reconstruir un blob, ejecuta git hash-object sobre una copia y escribe solo si coincide exactamente. Si no, rescata el árbol de trabajo en un clon nuevo y conserva el repositorio dañado.
Verifica repositorio y almacenamiento
La reparación termina cuando fsck ya no muestra el objeto alcanzable perdido o corrupto, los refs resuelven, la historia y cambios siguen presentes y un clon independiente hace checkout. Solo dangling puede ser normal.
Si la corrupción vuelve, aparecen más objetos o hay errores de E/S, memoria, energía o filesystem, detén la cirugía y revisa el almacenamiento. Conserva copias hasta verificar todos los cambios locales.
