Tecnología · GUÍA PRÁCTICA
¿Git dice “cannot lock ref”? Clasifica el sufijo antes de borrar nada
“is at… but expected”, “exists; cannot create” y “unable to resolve” son fallos distintos. Conserva el ref y los OID, detén escritores competidores y repara solo la rama demostrada.
“Cannot lock ref” es un prefijo de error, no un diagnóstico único. El resto de la línea indica una carrera de OID esperado, una colisión de nombre jerárquico, una referencia rota o un bloqueo que no pudo crearse.
Guarda la línea completa y los valores actuales antes de borrar nada. Detén fetchers o escritores CI, clasifica el sufijo y aplica una sola corrección estrecha que conserve trabajo nuevo.
Conserva ref, sufijo y OID exactos
Copia el error, comando, ruta y si aparece “remote:”. Registra git rev-parse --git-common-dir, git version, git status --short --branch y el ref completo.
Usa git show-ref --verify con el ref completo y git for-each-ref alrededor del namespace. Guarda el OID actual y el anunciado por el remoto antes de limpiar.
Trata “is at A but expected B” como carrera
Es protección compare-and-swap: Git esperaba B y volvió a leer A. Detén fetch de fondo, integraciones IDE y trabajos CI solapados; identifica quién cambió el ref.
Si A es válido, repite una sola vez un fetch o push fresco. No fuerces B ni borres el ref: podrías eliminar la actualización protegida.
Resuelve namespace y caso deliberadamente
Para “X exists; cannot create X/Y”, enumera refs locales y remotos. En almacenamiento por archivos, foo bloquea foo/bar. Acuerda el nombre con sus propietarios y conserva el OID antes de renombrar.
En Windows y sistemas equivalentes compara también sin distinguir mayúsculas. Un clon limpio confirma la colisión, pero no autoriza renombrar ramas remotas en silencio.
Separa bloqueo activo y referencia rota
Para “unable to resolve reference”, inspecciona el ref con Git: puede ser packed, loose, symbolic o reftable. Ejecuta git fsck --full y no edites packed-refs a mano.
Si existe .lock, demuestra que ningún proceso Git, hook, IDE, copia o tarea de servidor lo usa. Solo un lock huérfano de una operación detenida entra en la rama stale-lock.
Verifica una reparación estrecha
Para una corrección local demostrada, prefiere git update-ref con expected old OID. En colisión renombra o borra según acuerdo y luego fetch; en carrera basta un fresh retry.
Termina con git show-ref, git fsck --full, un fetch o push y comparación del OID remoto. Registra concurrencia, jerarquía, caso, lock interrumpido, permisos o ref roto.
