git rebase no continuará después de un borrado/modificar los conflictos

estoy en medio de un rebase de mi maestro a una rama etapagit rebase no continuará después de un borrado/modificar los conflictos

git checkout stage 
git rebase master

En algún momento he eliminado dos archivos modifica entonces los dos archivos de acuerdo a GIT.

warning: too many files, skipping inexact rename detection 
CONFLICT (delete/modify): test-recommendation-result.php deleted in HEAD and modified in [Bug] Fix test recommender. Version [Bug] Fix test recommender of test-recommendation-result.php left in tree. 
CONFLICT (delete/modify): test-recommendation.php deleted in HEAD and modified in [Bug] Fix test recommender. Version [Bug] Fix test recommender of test-recommendation.php left in tree. 
Failed to merge in the changes. 
Patch failed at 0015.

quiero decir "Sí git, adelante y borrar esos archivos" así que ....

git rm test-recommendation-result.php 
git rm test-recommendation.php 
git rebase --continue

Git dice:

Applying [Bug] Fix test recommender 
No changes - did you forget to use 'git add', Stupid? 

When you have resolved this problem run "git rebase --continue". 
If you would prefer to skip this patch, instead run "git rebase --skip". 
To restore the original branch and stop rebasing run "git rebase --abort".

digo "no hacer ¡llámame "estúpido" y haz lo que te dije que hicieras! "

Estamos ahora en un punto muerto. ¿Quién tiene razón y cómo soluciono esto?

Fuente

2011-04-01 Clutch

git me llama estúpido también – luckyging3r

do git add -A seguido de git rebase --continue. Esto debería agregar todos los cambios, incluida la eliminación de los archivos y luego continuar.

No hay garantía de que la confirmación no tenga otros archivos que no entren en conflicto y se fusionen. git rebase --skip perdería esos archivos. No quieres eso.

Espero que esto ayude.

Fuente

2011-04-01 17:20:47

Tiene razón en general, pero en este caso, parece que podemos deducir que no existen otros cambios. Git se habría quejado de otros conflictos, o el 'rebase --continuar' hubiera funcionado. – Cascabel

Esa es la excepción y no la regla. Todos los desarrolladores deben hacer esto ya que se ocupa de ambos casos. –

Te estás perdiendo el punto. El primer paso aquí es "verificar el resultado del estado de git". Si no tiene conflictos enumerados, y nada en etapas, entonces omitir es la opción correcta, y agregar/continuar no hará nada, como lo vio el OP. Si solo ha enumerado los cambios ordenados, no hubo conflicto en primer lugar, y puede continuar (la pregunta nunca se habría formulado). Si hay conflictos, la pregunta aún nunca se habría formulado, y su respuesta es peligrosa: debe solucionar los conflictos antes de agregar todo a ciegas. – Cascabel

Cuando falla todo lo demás, lea el mensaje.

Este parche intenta modificar dos archivos, pero ya se han eliminado; borrarlos de nuevo no hizo nada.

Simplemente ejecute git rebase --skip.

Fuente

2011-04-01 16:53:41

no hay garantía de que haya otros archivos que se fusionaron correctamente. el salto de rebase perdería esos cambios. –

Oh, pensé que rebase no se estaría quejando si otros archivos se fusionaron correctamente. –

El problema es que se quejó de que los 2 archivos tienen conflictos. Esa confirmación puede haber tenido más que solo esos 2 archivos que fueron cambiados. Si omite, omita también esos, no solo los que informaron conflictos. –

Apagué esto cuando una confirmación agregó un archivo binario que entraba en conflicto con un archivo existente.

que tiene por ella por:

borrar el archivo existente,
hacer un solo cambio de carácter a un comentario en un archivo diferente y
"git add" ing que el cambio irrelevante.

Git was happy again. :)

Fuente

2013-05-30 20:20:07

No hay una secuencia mágica de comandos para ejecutar siempre para resolver esta situación. Si los hubiera, los desarrolladores de GIT simplemente realizarían esa acción y no molestarían al usuario.

Tenga en cuenta que este error también puede ocurrir si está realizando una selección/trasplante/respaldo de cambios que afecten a un archivo que se volvió a factorizar o cambiar de nombre.

Por ejemplo, digamos que usted tiene rama llamada support/1.0 que tiene este aspecto:

 

    com.somewhere.package-a/ 
     MyClass.java 
     MyOtherClass.java

Ahora, supongamos que entre las versiones 1.0 y 1.5, esto quedó reprogramado.Así que ahora release/1.5 se parece a esto:

 

    com.somewhere.package/ 
     a/ 
     MyClass.java 
     ANewClass.java 
     b/ 
     MyOtherClass.java

Ahora, vamos a decir que usted tiene una rama de la característica de la versión 1.5 que está intentando hacer una copia de puerto a una rama de la característica con sede fuera de support/1.0. En esa confirmación, hubo cambios en los tres archivos de la versión 1.5 (MyClass.java, ANewClass.java y MyOtherClass.java).

Si intenta utilizar rebase o recogida llano de la cereza para ayudar con el back-puerto, una de dos cosas puede pasar:

Si los ficheros han sido renombrados como parte de los cambios de ser trasplantadas, o entre las confirmaciones principales inmediatas de los cambios siendo trasplantados, la detección de renombrado incorporada de GIT puede detectar que estos archivos son descendientes de los archivos con nombres originales, y simplemente aplican los cambios a los archivos originales.
Si los ficheros han sido renombrados suficientemente lejos en la historia de versión 1.5 (versión 1.0 después de la entrega), GIT le dirá que los archivos fueron borrados en release/1.0 porque no saben qué archivos en 1,0 corresponden a los cambios de 1.5.

ANewClass.java es casi seguro que desencadenar el error de haber sido eliminado, a menos que se añadió en uno de los cambios que está portado hacia atrás.

Por lo tanto, debido a que el código puede perderse si sigue ciegamente un conjunto de comandos para resolver esta situación, es por eso que GIT le solicita una guía manual.

Fuente

2017-04-19 14:19:14 GuyPaddock

git rebase no continuará después de un borrado/modificar los conflictos

Respuesta

Cuestiones relacionadas