git subreeree pull dice que el árbol de trabajo tiene modificaciones, pero el estado de git dice que no. ¿Lo que da?

Si hago esto en uno de mis repositorios:git subreeree pull dice que el árbol de trabajo tiene modificaciones, pero el estado de git dice que no. ¿Lo que da?

git subtree pull --prefix=frameworks/AquaticPrime --squash AquaticPrime

me sale esto:

Working tree has modifications. Cannot add.

Si hago esto (en el mismo lugar, por supuesto):

git status

Entiendo esto:

# On branch master 
nothing to commit (working directory clean)

No estoy muy seguro de lo que está pasando aquí. El comando git status implica que no tengo modificaciones, así que supongo que la extracción del subárbol de git se refiere a las modificaciones en una rama diferente relacionada con el subárbol, pero no está del todo claro.

¿Alguien puede proporcionar la iluminación?

Fuente

2010-09-02 Sam Deane

De un vistazo rápido a la fuente, impresiones 'git-subtree' que cuando 'git diff-índice CABEZA --exit de código - quiet' sale de "falla", es decir, existen cambios. ¿Qué sucede si ejecuta 'git diff-index HEAD'? – Cascabel

También podría probar la opción '-d' (depurar). – Cascabel

Cuando ejecuto git diff-index HEAD, aparece "fatal: ambiguous argument 'HEAD': revisión desconocida o ruta no en el árbol de trabajo.". Salida similar si utilizo el indicador de depuración -d. Entonces la pregunta es, ¿por qué HEAD sería desconocido? –

-4

Trate de tirar sin --squash como se describe en this stackoverflow question.

Fuente

2012-06-11 09:43:22

Gracias, me siento un poco grosero no votando/marcando su respuesta, pero la verdad es que ha pasado tanto tiempo que no lo hago use el subárbol más, ¡y realmente no puedo probar la respuesta para ver si funciona! –

Tengo el mismo problema y eliminar --squash no lo resuelve. – Alkaline

No usé squash para comenzar. De hecho, ni siquiera sé por qué pensarías que funcionaría porque la pregunta que publicaste no hizo preguntas sobre el mensaje que recibimos. –

Ya he solucionado esto. Mi problema me pareció que el repositorio era nuevo: nunca le había dedicado nada. Una vez que envié un archivo al repositorio, pude pasar este error.

Sin embargo, utilizando el comando git subtree add C:\gitTest\repos\subA -d --prefix subA me dieron el nuevo error:

fatal just how do you expect me to merge 0 trees?

Después de jugar un poco durante un minuto, me di cuenta de que se requiere una revisión específica puede pasar a ella. Así que este comando parece haber tenido éxito:

git subtree add C:\gitTest\repos\subA HEAD -d --prefix subA

Y, obviamente, no es necesario el indicador de depuración -d.

Fuente

2013-05-28 02:01:48

¡Muchas gracias ** muy ** mucho !! Su observación con respecto a los problemas con el repositorio vacío ha resultado ser también válida en el contexto de [esta pregunta sobre problemas con 'git tfs subárbol agregar'] (http://stackoverflow.com/questions/25886008/how-to-manage-two -tfs-projects-in-one-git-repository/38081315 # 38081315). El mensaje de error exacto era 'fatal: argumento ambiguo 'HEAD': revisión desconocida o ruta no en el árbol de trabajo' y todo era sobre" missing HEAD "en el maestro en repositorio vacío. – quetzalcoatl

Acabo de tener el mismo problema. De fuente GIT, se produce un error cuando el comando git diff-index HEAD devuelve resultado, incluso si git status dice que el árbol de trabajo está limpio.

Para evitar este error, en mi caso, me re-checkout de la rama actual del árbol de trabajo, y todo parece OK: git checkout <branch>

Es un poco confuso, pero si alguien puede explicar por qué ...

Fuente

2013-09-04 08:07:07 Koryonik

La descripción del problema es excelente, pero necesito un poco más de información para implementarla ... OH, simplemente quiso decir ejecutar "git checkout maestro" en el módulo principal (sin subárbol). ¡Estupendo! –

¡Gracias, funciona como un encanto! –

que acaba de tener este problema, cuando:

añadido un sub-árbol;
realizado, lo agregué incorrectamente (a un directorio incorrecto);
lo eliminó con rm;
intenté importarlo de nuevo (al lugar correcto).

Aunque era puppet diff - correctamente - que muestra nada, el git diff-index HEAD que aparece cada uno de los archivos que acaba de eliminar como "borrado" - a pesar de que nunca se me comprometo-ed (mucho menos push-ed) nada.

creo, esto es un error en Git (usando 2.7.0 aquí) ... Bug o no, el trabajo en torno a es cambiar a cualquier otra rama (con el habitual git checkout ....) y luego de vuelta a tuya. Espero, esto ayuda a alguien, incluso si no es el asker original.

Fuente

2016-04-14 18:51:54

git reset --hard fija a mí

De git reset --help

--hard Resets the index and working tree. Any changes to tracked files in the working tree since are discarded.

Fuente

2016-08-19 11:40:03 Anssi

git subreeree pull dice que el árbol de trabajo tiene modificaciones, pero el estado de git dice que no. ¿Lo que da?

Respuesta

Cuestiones relacionadas