Git conflicto de rebase con nada para fusionar?

Question

¿Qué significa cuando un git rebase encuentra un conflicto, pero no hay ningún problema aparente en el archivo? El archivo en cuestión no tiene marcadores de conflicto, y git mergetool dice "nada que fusionar".

Las opciones que se han restablecer o añadir :

# Unmerged paths: 
# (use "git reset HEAD <file>..." to unstage) 
# (use "git add/rm <file>..." as appropriate to mark resolution) 
# 
# both modified:  filename.js 

¿Cómo puedo saber de qué se trata y qué camino tomar?

git ls-files -s filename.js da 3 filas:

100644 d2c915b1d632b8ef8fbcf056824fb7fac7824ab9 1 filename.js 
100644 9010798f1d19ac712196b1fc9b0870fd332b1275 2 filename.js 
100644 b3ab7ec50812c73a3ec97bf0985f3226ec13cbc8 3 filename.js 

Según el manual bien, este comando nos dice que los bits de modo, el nombre del objeto, y el número de etapa. Los bits de modo son lo mismo. Entonces, ¿qué son 1, 2 y 3, y por qué son "ambos modificados", pero no muestran marcadores de conflicto?

Answer 1

Las versiones en el índice marcados 1, 2 y 3 tienen el siguiente significado:

1. El archivo como lo fue en un ancestro común de los dos confirmaciones que estés fusionan.
2. El archivo tal como estaba en HEAD, es decir, su confirmación actual cuando realizó la combinación.
3. El archivo tal como está en la confirmación que intenta fusionar en HEAD.

Mi fuente para esta información es the git manual's useful section on resolving conflicts.

La salida both modified en git status indica, por supuesto, que el archivo fue cambiado de diferentes maneras por los dos commits que está fusionando desde su antecesor común.

Es bastante misterioso para mí por qué no ve marcadores de conflicto en el archivo, sin embargo, que los blobs tienen diferentes nombres de objeto (hashes) en el resultado de git ls-files -s indica que byte a byte ciertamente tienen contenido diferente Si está contento con el archivo tal como está en su copia de trabajo, puede simplemente hacer git add filename.js y luego git rebase --continue. Sin embargo, en cualquier caso, es posible que desee saber cuáles fueron esas diferencias. Para hacer eso, me gustaría probar el siguiente:

git diff :2:filename.js filename.js 

... que mostrará las diferencias entre la versión en HEAD y su copia de trabajo actual. Del mismo modo, puede probar:

git diff :3:filename.js filename.js 

... para ver la diferencia entre la versión que se estaba fusionando y su copia de trabajo.

Answer 2

El 1, 2 y 3 de git ls-files -s representa la "etapa" de un 3-way merge: 1 es el antepasado común, 2 es la cabeza rama actual y 3 es la otra cabeza rama.En Linux, puede probar los siguientes comandos para ver qué hay de diferente entre los archivos:

$ git cat-file blob d2c915b1d632b8ef8fbcf056824fb7fac7824ab9 | xxd -ps 
$ git cat-file blob 9010798f1d19ac712196b1fc9b0870fd332b1275 | xxd -ps 
$ git cat-file blob b3ab7ec50812c73a3ec97bf0985f3226ec13cbc8 | xxd -ps