Este artículo analiza los submódulos de Git tratados como si fueran un gestor de paquetes y explica por qué la analogía se queda corta en casi cada paso del flujo de trabajo. El autor parte de un caso concreto: al intentar borrar un worktree que contenía submódulos con git worktree remove, Git lo rechazó y obligó a usar --force, algo que la documentación de git worktree recoge de forma específica para repositorios con submódulos, distinta del estado "sucio". El comando git worktree move llega más lejos y se niega en seco a mover cualquier worktree con submódulos, por una colisión interna entre dos funcionalidades del propio Git que el autor ya había estudiado en piezas previas sobre el flag --force.
El texto recorre las piezas del símil: el gitlink es la entrada de lockfile, .gitmodules es el manifesto y git submodule update ejecuta el install con un anclaje tan preciso como el de cualquier gestor de paquetes (un SHA exacto). A partir de ahí desglosa los puntos de fricción. En resolución, el sistema solo conoce una URL por submódulo y no hay forma de localizar servidores a partir de un SHA, así que cualquier cambio de nombre, traslado o privatización del repositorio upstream rompe todas las anclas aguas abajo; git submodule sync y la configuración global url.<base>.insteadOf aparecen como.workarounds habituales en CI. En instalación, el clon plano deja los submódulos vacíos hasta ejecutar update --init; los flags --init y --remote modifican el comportamiento por defecto de formas que el propio nombre del comando confunde. En almacenamiento, los submódulos viven en $GIT_DIR/modules/<name> y eliminarlos exige tres pasos coordinados (git rm, git submodule deinit y un rm -rf manual del directorio absorbido). El artículo también recoge el debate abierto en la lista de correo de Git, con un RFC y una serie de parches que proponen tratar cada checkout de submódulo como un worktree de un clon compartido, lo que aliviaría la colisión entre worktrees y submódulos que motiva toda la pieza.