Git submodule head ‘la referencia no es un árbol’ error

12 minutos de lectura

Git submodule head la referencia no es un arbol error
mauricio scheffer

Tengo un proyecto con un submódulo que apunta a una confirmación no válida: la confirmación del submódulo se mantuvo local y cuando intento recuperarla de otro repositorio, obtengo:

$ git submodule update
fatal: reference is not a tree: 2d7cfbd09fc96c04c4c41148d44ed7778add6b43
Unable to checkout '2d7cfbd09fc96c04c4c41148d44ed7778add6b43' in submodule path 'mysubmodule'

Sé cuál debería ser el submódulo HEAD, ¿hay alguna forma de que pueda cambiar esto localmente, sin presionar desde el repositorio que lo hace haber cometido 2d7cfbd09fc96c04c4c41148d44ed7778add6b43 ?

No estoy seguro si estoy siendo claro… aquí hay una situación similar Encontré.

  • “fatal: la referencia no es un árbol” en referencia a los submódulos parece generalmente significar que la confirmación del submódulo que el repositorio principal espera aún no se ha enviado, o está arruinada de alguna otra manera. Para nosotros, este mensaje de error confuso se resolvió simplemente presionando un submódulo que alguien olvidó presionar.

    – Chris Moschini

    27/01/2014 a las 19:45

  • @ChrisMoschini: acabo de tener ese problema, y ​​esa fue mi “solución”, presioné y saqué el repositorio principal, pero olvidé enviar mi última confirmación al repositorio del submódulo. ¡Gracias!

    – Rótem

    10 mayo 2016 a las 13:24

  • Tal vez olvidó enviar las últimas confirmaciones de submódulos

    – Hafenkranich

    20 de noviembre de 2016 a las 2:58

Git submodule head la referencia no es un arbol error
chris johnsen

Suponiendo que el repositorio del submódulo contiene una confirmación que desea usar (a diferencia de la confirmación a la que se hace referencia desde el estado actual del superproyecto), hay dos formas de hacerlo.

El primero requiere que ya conozca la confirmación del submódulo que desea usar. Funciona desde “adentro hacia afuera” ajustando directamente el submódulo y luego actualizando el superproyecto. El segundo funciona desde “afuera, adentro” al encontrar la confirmación de superproyectos que modificó el submódulo y luego restablecer el índice del superproyecto para hacer referencia a una confirmación de submódulo diferente.

De adentro hacia afuera

Si ya sabe qué compromiso desea que use el submódulo, cd al submódulo, verifique el compromiso que desea, luego git add y git commit de vuelta en el super-proyecto.

Ejemplo:

$ git submodule update
fatal: reference is not a tree: e47c0a16d5909d8cb3db47c81896b8b885ae1556
Unable to checkout 'e47c0a16d5909d8cb3db47c81896b8b885ae1556' in submodule path 'sub'

Vaya, alguien hizo una confirmación de superproyecto que hace referencia a una confirmación no publicada en el submódulo sub. De alguna manera, ya sabemos que queremos que el submódulo esté en la confirmación. 5d5a3ee314476701a20f2c6ec4a53f88d651df6c. Ve allí y compruébalo directamente.

Checkout en el Submódulo

$ cd sub
$ git checkout 5d5a3ee314476701a20f2c6ec4a53f88d651df6c
Note: moving to '5d5a3ee314476701a20f2c6ec4a53f88d651df6c' which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
  git checkout -b <new_branch_name>
HEAD is now at 5d5a3ee... quux
$ cd ..

Dado que estamos revisando un compromiso, esto produce un HEAD separado en el submódulo. Si quiere asegurarse de que el submódulo está usando una rama, entonces use git checkout -b newbranch <commit> para crear y verificar una rama en el compromiso o verificar la rama que desea (por ejemplo, una con el compromiso deseado en la punta).

Actualizar el superproyecto

El pago en el submódulo se refleja en el superproyecto como un cambio en el árbol de trabajo. Por lo tanto, debemos organizar el cambio en el índice del superproyecto y verificar los resultados.

$ git add sub

Compruebe los resultados

$ git submodule update
$ git diff
$ git diff --cached
diff --git c/sub i/sub
index e47c0a1..5d5a3ee 160000
--- c/sub
+++ i/sub
@@ -1 +1 @@
-Subproject commit e47c0a16d5909d8cb3db47c81896b8b885ae1556
+Subproject commit 5d5a3ee314476701a20f2c6ec4a53f88d651df6c

La actualización del submódulo fue silenciosa porque el submódulo ya está en la confirmación especificada. La primera diferencia muestra que el índice y el árbol de trabajo son iguales. La tercera diferencia muestra que el único cambio por etapas es mover el sub submódulo a una confirmación diferente.

Cometer

git commit

Esto confirma la entrada del submódulo arreglado.


De fuera hacia dentro

Si no está seguro de qué compromiso debe usar del submódulo, puede consultar el historial en el superproyecto para guiarlo. También puede administrar el reinicio directamente desde el superproyecto.

$ git submodule update
fatal: reference is not a tree: e47c0a16d5909d8cb3db47c81896b8b885ae1556
Unable to checkout 'e47c0a16d5909d8cb3db47c81896b8b885ae1556' in submodule path 'sub'

Esta es la misma situación que la anterior. Pero esta vez nos centraremos en arreglarlo desde el superproyecto en lugar de sumergirlo en el submódulo.

Encuentra la confirmación errante del superproyecto

$ git log --oneline -p -- sub
ce5d37c local change in sub
diff --git a/sub b/sub
index 5d5a3ee..e47c0a1 160000
--- a/sub
+++ b/sub
@@ -1 +1 @@
-Subproject commit 5d5a3ee314476701a20f2c6ec4a53f88d651df6c
+Subproject commit e47c0a16d5909d8cb3db47c81896b8b885ae1556
bca4663 added sub
diff --git a/sub b/sub
new file mode 160000
index 0000000..5d5a3ee
--- /dev/null
+++ b/sub
@@ -0,0 +1 @@
+Subproject commit 5d5a3ee314476701a20f2c6ec4a53f88d651df6c

OK, parece que salió mal en ce5d37cpor lo que restauraremos el submódulo desde su padre (ce5d37c~).

Alternativamente, puede tomar la confirmación del submódulo del texto del parche (5d5a3ee314476701a20f2c6ec4a53f88d651df6c) y use el proceso anterior de “adentro, afuera” en su lugar.

Checkout en el Super-proyecto

$ git checkout ce5d37c~ -- sub

Esto restablece la entrada del submódulo para sub a lo que fue en cometer ce5d37c~ en el superproyecto.

Actualizar el submódulo

$ git submodule update
Submodule path 'sub': checked out '5d5a3ee314476701a20f2c6ec4a53f88d651df6c'

La actualización del submódulo salió bien (indica un HEAD desconectado).

Compruebe los resultados

$ git diff ce5d37c~ -- sub
$ git diff
$ git diff --cached
diff --git c/sub i/sub
index e47c0a1..5d5a3ee 160000
--- c/sub
+++ i/sub
@@ -1 +1 @@
-Subproject commit e47c0a16d5909d8cb3db47c81896b8b885ae1556
+Subproject commit 5d5a3ee314476701a20f2c6ec4a53f88d651df6c

La primera diferencia muestra que sub ahora es lo mismo en ce5d37c~. La segunda diferencia muestra que el índice y el árbol de trabajo son iguales. La tercera diferencia muestra que el único cambio escalonado es mover el sub submódulo a una confirmación diferente.

Cometer

git commit

Esto confirma la entrada del submódulo arreglado.

  • En el enfoque “Afuera, Adentro”, ¿podría aclarar por qué “parece que salió mal en ce5d37c?” ¿Qué dedos comete aquel como el malo?

    – Garret Albright

    18 de febrero de 2011 a las 21:53


  • @Garrett: La suposición es e47c0a es una confirmación que no existe en el repositorio local para subsin embargo, el superproyecto sub apunta a ese compromiso. Esto podría haber sucedido porque alguien más creó e47c0a en su copia de subactualizó su superproyecto para apuntar a ese compromiso e impulsó el superproyecto sin presionar e47c0a al repositorio central/compartido para sub. Cuando extraemos del superproyecto central/compartido, obtenemos un compromiso que apunta sub para e47c0apero no podemos “ver” ese compromiso. ce5d37c es sospechoso porque, según la diferencia, introdujo e47c0a.

    – Chris Johnsen

    18 de febrero de 2011 a las 23:35

  • Todavía queda bastante vago dónde está el hash específico del sub guardado en el repositorio principal que lo tiene como un submódulo, y si se puede manipular o no directamente al HEAD actual de sub directamente, sin depender de un estado anterior del repositorio principal, lo que no siempre ayuda.

    – matanster

    29/10/2015 a las 11:21


  • @matanster: se almacena directamente en la base de datos de objetos de Git

    – Sr_y_Sra_D

    7 mayo 2016 a las 14:39

prueba esto:

git submodule sync
git submodule update

  • Desafortunadamente, no para mí, uno de nuestros submódulos fue atacado por el repositorio principal de git con un comando de agregar, ahora tiene problemas para deshacerlo

    – Daniel

    15/02/2012 a las 18:00

  • Trabajó para mí también. Aunque me encantaría saber por qué.

    – BenBtg

    20 de julio de 2012 a las 13:42

  • Resulta que haciendo un git submodule sync es necesario en escenarios donde la URL del control remoto para un submódulo dado ha cambiado. En nuestro caso, agregamos nuestro submódulo desde un repositorio público y luego cambiamos la URL a una bifurcación privada, y nos metimos en este problema en particular.

    – Samscam

    20 de diciembre de 2012 a las 16:44

  • Por ejemplo: tenía un repositorio (A) configurado con un submódulo que apuntaba a mi repositorio github (B). Creé una rama en el repositorio A porque quería señalar B en el repositorio github de otra persona. Después de luchar un poco con eso y confirmar la rama, cambié mi repositorio A a maestro y tuve este problema con el repositorio B. La solución de @Lonre Wang lo arregló.

    – fbicknel

    20 mayo 2014 a las 19:20

  • Asumiendo que nadie REALMENTE lo arruinó (en cuyo caso necesitarías la excelente respuesta de Chris Johnsen), la respuesta de Lonre Wang debería solucionar el problema… A MENOS que tus submódulos tengan sus propios submódulos (y el problema está dentro de un submódulo). En ese caso, debe ingresar al submódulo que tiene el submódulo con el problema y ejecutar los comandos anteriores. Tenga en cuenta que la actualización tiene una opción –recursive (actualización del submódulo git –recursive), pero la sincronización no; realmente tiene que ejecutar manualmente ‘git submodule sync’ dentro del submódulo que tiene el sub(sub)módulo problemático. Este era mi problema ;).

    – Carlos Wood

    11/10/2016 a las 23:21

Este error puede significar que falta una confirmación en el submódulo. Es decir, el repositorio (A) tiene un submódulo (B). A quiere cargar B para que apunte a una determinada confirmación (en B). Si ese compromiso falta de alguna manera, obtendrá ese error. Una vez causa posible: la referencia a la confirmación se envió en A, pero la confirmación real no se envió desde B. Entonces, comenzaría allí.

Es menos probable que haya un problema de permisos y que no se pueda extraer la confirmación (posible si está usando git+ssh).

Asegúrese de que las rutas de los submódulos se vean bien en .git/config y .gitmodules.

Una última cosa para intentar: dentro del directorio del submódulo: git reset HEAD –hard

  • Ya expliqué que en la pregunta… la pregunta en sí era cómo resolverlo. Y ya se ha respondido con éxito hace casi dos años… Los permisos no tienen nada que ver con esto.

    –Mauricio Scheffer

    15 de noviembre de 2011 a las 22:08


  • Lo dijiste, ciertamente no lo explicaste.

    – Daniel Tsadok

    15 de noviembre de 2011 a las 23:35

  • esto me ayudó: “dentro del directorio del submódulo: git reset HEAD –hard”

    – k2s

    15 de febrero de 2012 a las 15:08

  • el “git reset HEAD –hard” también me ayudó… nada más funcionó. Probé las soluciones anteriores también, sin dados. ¡Gracias!

    – Virgilio

    23 de noviembre de 2012 a las 15:40

Git submodule head la referencia no es un arbol error
chriskelly

Causa posible

Esto puede suceder cuando:

  1. Los submódulos se han editado en su lugar
  2. Submódulo(s) comprometido(s), que actualiza el hash del submódulo al que se apunta
  3. Submódulo(s) no empujado.

por ejemplo, algo como esto sucedió:

$ cd submodule
$ emacs my_source_file  # edit some file(s)
$ git commit -am "Making some changes but will forget to push!"

Debería haber empujado el submódulo en este punto.

$ cd .. # back to parent repository
$ git commit -am "updates to parent repository"
$ git push origin master

Como resultado, es posible que el usuario remoto no pueda encontrar las confirmaciones faltantes porque todavía están en el disco local.

Solución

Informa a la persona que modificó el submódulo para empujar, es decir

$ cd submodule
$ git push

Es posible que su sucursal no esté actualizada, una solución simple, pero intente git fetch

  • Esto es lo que me solucionó. La confirmación estaba visible en el repositorio del submódulo, simplemente no lo sabía localmente.

    – bklaric

    27 de julio de 2020 a las 9:10

Recibí este error cuando lo hice:

$ git submodule update --init --depth 1

pero la confirmación en el proyecto principal apuntaba a una confirmación anterior.

Eliminando la carpeta del submódulo y ejecutando:

$ git submodule update --init

NO resolvió el problema. Eliminé el repositorio y lo intenté de nuevo sin el indicador de profundidad y funcionó.

Este error ocurre en Ubuntu 16.04 git 2.7.4, pero no en Ubuntu 18.04 git 2.17.

@pavan kumar anota en un comentario:

Acabo de aumentar el conteo de profundidad para incluir la confirmación anterior y funcionó.

  • Esto es lo que me solucionó. La confirmación estaba visible en el repositorio del submódulo, simplemente no lo sabía localmente.

    – bklaric

    27 de julio de 2020 a las 9:10

1646759838 858 Git submodule head la referencia no es un arbol error
pasamio

Esto también puede suceder cuando tiene un submódulo que apunta a un repositorio que fue reorganizado y el compromiso dado “ha desaparecido”. Si bien la confirmación aún puede estar en el repositorio remoto, no está en una rama. Si no puede crear una nueva rama (por ejemplo, no su repositorio), tendrá que actualizar el superproyecto para que apunte a una nueva confirmación. Alternativamente, puede enviar una de sus copias de los submódulos a otro lugar y luego actualizar el superproyecto para que apunte a ese repositorio.

¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad