salir - Git rebase no continuará después de un conflicto de eliminar/modificar

salir de merge git

Question

Estoy en medio de una rebase de mi maestro a una rama de escenario

git checkout stage
git rebase master

En algún momento eliminé dos archivos y luego modifiqué los dos archivos de acuerdo con 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, ve y elimina 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 me llames" Estúpido "y solo haz lo que te dije que hicieras!"

Ahora estamos en un punto muerto. ¿Quién tiene razón y cómo arreglo esto?

Answer 1

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

Este parche está intentando modificar dos archivos, pero ya se han eliminado; eliminarlos de nuevo no hizo nada.

Simplemente ejecuta git rebase --skip .

Answer 2

Golpeé esto cuando un commit agregó un archivo binario que estaba en conflicto con un archivo existente.

Lo conseguí por:

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

Git estaba feliz de nuevo. :)

Answer 3

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

Tenga en cuenta que este error también puede suceder si está realizando cambios de selección / trasplante / backporting que afectan a un archivo que se ha rediseñado o cambiado de nombre.

Por ejemplo, digamos que tienes una rama llamada support/1.0 que se ve así:

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

Ahora, supongamos que entre las versiones 1.0 y 1.5, esto se reformuló. Así que ahora la release/1.5 ve así:

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

Ahora, supongamos que tiene una rama de características desde la versión 1.5 que está intentando realizar una conexión a una rama de características basada en 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 trata de usar rebase o selección de cereza simple para ayudar con el puerto trasero, puede suceder una de estas dos cosas:

• Si los archivos se renombraron como parte de los cambios que se están trasplantando, o entre los compromisos primarios inmediatos de los cambios que se están transplantando, la detección incorporada de cambio de nombre de GIT puede detectar que estos archivos son descendientes de los archivos con nombres originales, y simplemente aplicar los cambios a los archivos originales.

• Si los archivos fueron renombrados lo suficientemente atrás en el historial de la versión 1.5 (después de la versión 1.0 enviada), GIT le dirá que los archivos fueron eliminados en la release/1.0 porque no sabe qué archivos en 1.0 corresponden a los cambios de 1.5. .

ANewClass.java casi con certeza activará el error sobre la ANewClass.java , a menos que se haya agregado en uno de los cambios que se están ANewClass.java anterior.

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 orientación manual.

Answer 4

hacer 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 tuviera otros archivos que no estuvieran en conflicto y que deban fusionarse. git rebase --skip perdería esos archivos. Tú no quieres eso.

Espero que esto ayude.