No se puede encontrar `HEAD` en el conflicto de git rebase?

Estoy tratando de volver a establecer la base para aplastar los commits, y me da un conflicto:

<username>:~/path/to/director$git rebase -i HEAD~6 error: could not apply 0111a7a... <commit message> When you have resolved this problem, run "git rebase --continue". If you prefer to skip this patch, run "git rebase --skip" instead. To check out the original branch and stop rebasing, run "git rebase --abort". Could not apply 0111a7acsadd9a9d98a9003a560a390a50a22afa3af546f42101... <full commit message> 

Luego, hago lo siguiente para encontrar el conflicto:

 find . -name "*.py" -exec egrep ".*HEAD.*" {} \; 

como sé que solo cambié los files de Python, utilizo el *.py globbing. Sin embargo, ¡no se muestran resultados! ¿Hay alguna manera de encontrar exactamente cuál es el problema?

git status y git diff están limpios.

Antes de la respuesta a continuación, quiero señalar una cosa: si solo quieres aplastar una serie de confirmaciones en una única confirmación, la manera más fácil suele ser simplemente combinar la git reset --soft con la única confirmación deseada. Vea esta respuesta de Chris Johnsen y esta respuesta de VonC , y observe el último párrafo de viñeta de VonC.


No podemos decir con certeza qué está sucediendo, porque no nos ha mostrado suficiente información, pero aquí hay un escenario común en el que git rebase le dice que no puede aplicar algún compromiso, aunque tampoco hay modificaciones mostradas por el git status . Esto no es lo mismo que tu caso (estás modificando tus propios commits en tu propia HEAD~6 , lo que hace que esto sea less probable), pero nuevamente no hemos visto suficiente información tuya, así que lo presento como un ejemplo .

Digamos que estás modificando una serie de dos o más confirmaciones. El primero corrige la ortografía de la palabra word en la línea 3 de un file de text. El segundo y cualquier commit posterior hacen otro con otros files. Estos cambios se realizaron en branket bran , pero desde entonces ha ejecutado git fetch y / o decidió moverlos a branch master o lo que sea.

Mientras tanto, resulta que alguien más también corrigió la ortografía de la palabra en la línea 3 de ese file de text, junto con la ortografía de la ortografía de la palabra en la línea 12. Por lo tanto, su solución es un subset de su solución. No es exactamente la misma solución, solo corrigió una palabra, arreglaron dos, pero su corrección no se puede aplicar ya que la palabra de word ya está escrita correctamente en la línea 3 del file de text.

Git no puede entender que esto está bien. Depende de usted descubrir que su solución, aunque es diferente de la solución "ascendente" en la que se basa, ya no es necesaria. En este caso (pero no en otros casos), simplemente debe omitir la confirmación.

Aquí hay una session de ejemplo donde esto ha ocurrido:

 $ * abda13a (master) fix two words | * 9e7ed64 (HEAD, bran) add a file | * 144d5a6 fix one word |/ * ac7be27 initial 

Echemos un vistazo a commit 144d5a6 :

 $ git show bran^ commit 144d5a66949cdd40fd92b0846d5b0ce00ebcdd8c Author: [networkingacted] Date: [networkingacted] fix one word diff --git a/README.txt b/README.txt index c37e4c4..983e649 100644 --- a/README.txt +++ b/README.txt @@ -1,6 +1,6 @@ This readme file has at least one -wurd +word that is misspelled. There may be 

Ahora veamos el commit-most commit de master :

 $ git show master commit abda13a47f5b5d968a09eedaf5cc573ba35a3dee Author: [networkingacted] Date: [networkingacted] fix two words diff --git a/README.txt b/README.txt index c37e4c4..867d98f 100644 --- a/README.txt +++ b/README.txt @@ -1,6 +1,6 @@ This readme file has at least one -wurd +word that is misspelled. There may be @@ -9,7 +9,7 @@ words, since the point of this file is to allow someone -to fix the speeling +to fix the spelling of any of the misspelled words. 

Ahora vamos a volver a establecer la base de la twig actual (que es bran ) en el master , pero de forma interactiva:

 $ git rebase -i master [the editor comes up with both commits selected as `pick`] [I exit the editor with the same `pick`s] The previous cherry-pick is now empty, possibly due to conflict resolution. If you wish to commit it anyway, use: git commit --allow-empty Otherwise, please use 'git reset' rebase in progress; onto abda13a You are currently rebasing branch 'bran' on 'abda13a'. nothing to commit, working directory clean Could not apply 144d5a66949cdd40fd92b0846d5b0ce00ebcdd8c... fix one word 

(Esto es con git 2.3.7, dicho sea de paso, las versiones anteriores ni siquiera notan que la selección de cereza se ha vuelto vacía, y simplemente se quejan de que no se puede aplicar el compromiso. No está claro para mí por qué se aconseja git reset ; eso no es necesario en este momento. Sin embargo, git 2.3.7 ahora está bastante desactualizado, debería actualizarlo).


1 Esto realmente depende de otras cosas. Con git 2.3.7, ahora es lo suficientemente inteligente como para detectar este caso para una database no interactiva . Usando la configuration inicial desde arriba:

 $ git rebase master First, rewinding head to replay your work on top of it... Applying: fix one word Using index info to reconstruct a base tree... M README.txt Falling back to patching base and 3-way merge... No changes -- Patch already applied. Applying: add a file $ git log --oneline --graph --decorate --all * c8f1815 (HEAD, bran) add a file * abda13a (master) fix two words * ac7be27 initial 

En este caso, la rebase no interactiva descubrió que mi "corregir una palabra" era networkingundante con "corregir dos palabras" y simplemente se saltó, por lo que la secuencia final de confirmaciones en bran es realmente la única confirmación restante, con " arregla dos palabras "en el master como su padre.

Normalmente, el git status debería mostrarle un file en conflicto. No debería estar buscando HEAD, pero para <<<<<< , ====== o >>>>>> .

Como dice que el git status está limpio, es posible que su confirmación se haya quedado vacía. Puede verificar lo que está en la confirmación usando

 git show 0111a7a 

si su compromiso se ha quedado vacío, debe omitirlo, usando

 git rebase --skip