Obtenga “asegúrese de que el archivo .gitmodules esté en el árbol de trabajo” cuando ejecute el comando agregar submódulo de git

Preguntas GIT
⏰ 5 minutos de lectura

Avatar de usuario de Urraca
Urraca

Soy nuevo en git, actualmente estoy buscando portar algunos proyectos grandes de mercurial. Tenemos un proyecto raíz que solo contiene las referencias a todos los proyectos externos (submódulos en git). Estoy tratando de recrear esto en git.

He importado un proyecto (foo) a githib. Creé un nuevo proyecto vacío (raíz) y lo cloné localmente. Quiero agregar Foo como un submódulo usando

git submodule add https://github.com/.../foo.git

desde /c/Work/GitHub/root (maestro)

pero sigo recibiendo “asegúrese de que el archivo .gitmodules esté en el árbol de trabajo”.

Mirando la documentación, la primera ejecución de este comando debería crear el archivo .gitmodules, pero recibo este error incluso si lo creo a mano. Buscar este error en Google solo devuelve los archivos de origen con el error, pero no explica por qué lo obtengo. Supongo que es solo mi pobre comprensión de git.

¿Qué estoy haciendo mal?

EDITAR: También lo he intentado.

mkdir test
cd test
git init
git submodule add https://github.com/.../foo.git

Me sale el mismo error.

  • Proporcione un ejemplo completo con comandos exactos. Si es necesario, elija un repositorio de prueba público para tratarlo como un submódulo.

    – José

    26 de mayo de 2020 a las 11:28

  • OK lo encontré, parece una instalación corrupta de git. Lo eliminé por completo y lo reinstalé y el problema desapareció. Gracias por mirar esto conmigo.

    – Urraca

    26 de mayo de 2020 a las 11:53

El verificar que probablemente estés fallando es:

int is_writing_gitmodules_ok(void)
{
        struct object_id oid;
        return file_exists(GITMODULES_FILE) ||
                (get_oid(GITMODULES_INDEX, &oid) < 0 && get_oid(GITMODULES_HEAD, &oid) < 0);
}

Esto significa que el archivo existe localmente o no existen en el área de ensayo o el actual HEAD comprometerse.

has usado git addpero luego lo eliminó del directorio de trabajo.

Usar git restore .gitmodules (o similar) para devolver el archivo existente a su directorio de trabajo.

  • Saludos por la respuesta, todavía no he ejecutado un complemento de git en este repositorio. Ejecuté el comando de todos modos pero obtuve ‘error: pathspec ‘.gitmodules’ no coincidió con ningún archivo conocido por git ‘

    – Urraca

    26 de mayo de 2020 a las 10:03

  • git restore -s HEAD .gitmodules sería el comando para recuperarlo de la última confirmación.

    – José

    26 de mayo de 2020 a las 10:36

  • mismo error, mi repositorio solo tiene una confirmación desde que lo creé en github. Solo tiene un archivo de ignorar. Lo cloné localmente y ejecuté el comando del submódulo como la primera operación en él.

    – Urraca

    26 de mayo de 2020 a las 11:10

  • Si ayuda, acabo de crear un nuevo repositorio, creé una carpeta de prueba, ejecuté git init y luego el comando del submódulo, obtuve el mismo error.

    – Urraca

    26 de mayo de 2020 a las 11:12

Probablemente eliminó su .gitmodule o tiene cambios en .gitmodule escenificado.

Intente restaurar el archivo usando git restore .gitmodule.

Si eso no ayuda, intente verificar git status para asegurarse de que no se escenifique nada; de lo contrario ejecutar git reset .gitmodule.

El restablecimiento completo, por ejemplo, a la última confirmación o la confirmación de todos los cambios, resolvió el problema para mí.

Creo que el mensaje debería ser en este caso algo así como “confirmar los cambios primero” más o menos.

Había algo mal con mi instalación de git. Lo desinstalé y lo volví a instalar, el error desapareció.

Teniendo en cuenta la versión actual de git-submodule.sh falla en:

 if ! git submodule--helper config --check-writeable >/dev/null 2>&1

Si es posible que tuviera un proceso que mantuviera un control sobre su .gitmodulesevitando cualquier “git submodule add” comando para modificarlo.

Tenga en cuenta que esto cambiará ligeramente con Git 2.33 (Q3 2021), con la reescritura de “git submodule“(hombre) en C, lo que sí impacta git submodule add:

Ver cometer bbe3165 (23 de julio de 2021) por jeff rey (peff).
Ver cometer 8c8195e, cometer a98b02c, cometer 0008d12 (10 de julio de 2021), y cometer 84069fc (06 de julio de 2021) por Atharva Raykar (tfidfwastaken).
(Combinado por Junio ​​C Hamano — gitster — en cometer 10f57e004 ago 2021)

submodule: prefijo morir mensajes con ‘fatal’

Firmado por: Atharva Raykar
Tutorizado por: Christian Couder
Tutorizado por: Shourya Shukla

El estandar die() La función que se usa en el código C antepone todos los mensajes que se le pasan con ‘fatal:’.
Esto no sucede con el die utilizado en ‘git-submodule.sh’.

Prefijemos cada uno de los mensajes de matriz de shell con ‘fatal:’ para que cuando se conviertan a código C, los mensajes de error permanezcan igual que antes de la conversión.

Tenga en cuenta que la versión shell de die sale con el código de error 1, mientras que la versión C sale con el código de error 128. En la práctica, esto no cambia ningún comportamiento, ya que ninguna funcionalidad en ‘agregar submódulo’ y ‘actualizar submódulo’ depende del valor del código de salida.

Y:

submodule--helper: introduce el subcomando add-clone

Firmado por: Atharva Raykar
Tutorizado por: Christian Couder
Tutorizado por: Shourya Shukla
Basado en el parche de: Shourya Shukla
Basado en el parche de: Prathamesh Chavan
Ayudado por: Đoàn Trần Công Danh

Agreguemos un nuevo “add-clone” subcomando a git submodule--helper con el objetivo de convertir parte del código shell en git-submodule.sh relacionado con git submodule add(hombre) en código C.
Este nuevo subcomando clona el repositorio que se va a agregar y se desprotege en la rama adecuada.

Esto está destinado a ser una conversión fiel que deja el comportamiento de ‘cmd_add()‘ guión sin cambios.

Por si alguien más tiene este problema. Había algo mal con mi instalación de git. Lo desinstalé y lo volví a instalar, el error desapareció.

¿Ha sido útil esta solución?