Tecnología · GUÍA PRÁCTICA
¿Git submodule muestra “not our ref”? Rastrea el commit fijado antes de sustituirlo
El hash procede del superproyecto, no de la rama esperada. Registra el gitlink, comprueba la URL efectiva y demuestra si el objeto es local, accesible o ausente antes de sincronizar, publicar, crear un fork o cambiar el commit.
“Not our ref” no pide añadir más opciones --force. Indica que el superproyecto solicitó un objeto exacto que la ruta actual no entregó. Conserva esa solicitud antes de cambiarla.
El orden seguro es registro, ruta, objeto y reparación: identifica el OID del gitlink, confirma la URL efectiva y demuestra existencia local y acceso remoto antes de actuar.
Congelar el fallo y leer el gitlink
Antes de rm -rf, deinit, --force o --remote, guarda el commit del superproyecto que falla, el error completo, la ruta y el trabajo local. git ls-tree HEAD -- path/to/submodule muestra una entrada de modo 160000 con el OID exacto esperado.
Ese OID es el primer hecho. El modelo oficial lo llama gitlink; una rama en .gitmodules no lo sustituye. Si CI muestra otro hash, inspecciona el commit exacto que falló, no la punta actual de la rama.
Comprobar la URL que Git usa realmente
Compara las URL de submodule en .git/config y .gitmodules. La inicialización copia la URL y los cambios posteriores de .gitmodules no reescriben un checkout antiguo. Así puede pedirse el OID correcto al repositorio equivocado.
Si el proyecto cambió de host, ejecuta git submodule sync --recursive y vuelve a comprobar. sync no crea el objeto ni concede acceso. Registra la URL sin credenciales y corrige la configuración o secretos de CI.
Separar existencia local, refs anunciadas y acceso
Dentro del submodule, git cat-file -e OID^{commit} comprueba el objeto exacto. Conserva un almacén que solo exista en la máquina original. El fallo frecuente es publicar el gitlink del superproyecto antes de publicar el commit del submodule.
git ls-remote --heads --tags URL muestra refs anunciadas, no todos los objetos inalcanzables; una ausencia no prueba borrado. Haz un fetch normal con la misma identidad y conserva el resultado.
Elegir una reparación que preserve el significado
Si la URL está obsoleta, sincroniza y reintenta el mismo OID. Si el objeto es solo local, publícalo en un remoto propio o crea un fork autorizado y actualiza la URL. Si existe en el host pero CI no accede, repara permisos.
Solo si el OID es irrecuperable o se desea cambiar la dependencia, prueba un commit sustituto, añade la ruta del submodule y confirma el nuevo gitlink. Documenta OID antiguo y nuevo, URL y motivo.
Usar --remote y el reclonado como pruebas
update normal usa el OID fijado; --remote cambia a la punta de una rama remota. Puede funcionar seleccionando otro commit, así que úsalo solo si seguir una rama es la política elegida.
Un clon limpio verifica la reproducibilidad tras la reparación, pero no publica un objeto local ni arregla una ruta antigua. Prevén recaídas con push --recurse-submodules=check/on-demand, revisión de URL y CI sobre el commit exacto.
