git - ¿Por qué esta selección tiene un conflicto?

cherry-pick git-cherry-pick

Question

Sé que git cherry-pick es un comando que se usa para aplicar los cambios de confirmación especificados, pero creo que realmente no entiendo cómo funciona.

Digamos que un repo actúa así:

git init

echo a>a
git add .; git commit -am ''master add line a''

git checkout -b dev
echo b>>a
git commit -am ''dev add line b''
echo c>>a
git commit -am ''dev add line c''

git checkout master

git cherry-pick dev

Pensé que el comando cherry-pick funcionaría bien y cambiaría el archivo a a:

a

c

Pero de hecho recibí el siguiente mensaje:

error: could not apply 08e8d3e... dev add line c
hint: after resolving the conflicts, mark the corrected paths
hint: with ''git add <paths>'' or ''git rm <paths>''
hint: and commit the result with ''git commit''

Y luego corro:

git diff

salida:

diff --cc a
index 7898192,de98044..0000000
--- a/a
+++ b/a
@@@ -1,1 -1,3 +1,6 @@@
  a
++<<<<<<< HEAD
++=======
+ b
+ c
++>>>>>>> 11fff29... abc

Entonces mi pregunta es: ¿Por qué hay un conflicto como los shows de git-diff? ¿Cuáles son los detalles del trabajo de cherry-pick en este caso?

Answer 1

Intente nuevamente su selección de cerezas después de :

git config merge.conflictstyle diff3

Obtendrá un diff más detallado:

<<<<<<< HEAD
||||||| parent of 5b2a14c... dev add line c
b
=======
b
c
>>>>>>> 5b2a14c... dev add line c

Muestra que, al aplicar el parche representado por la CABEZA del dev ( c ), Git no conoce un antepasado común; difiere a

• el padre inmediato del compromiso seleccionado (que muestra que agrega una línea '' c '' después de una línea '' b '')
• la confirmación de destino (que no muestra ninguna línea b encima de la cual podría aplicar el cambio agregado '' c '')

De ahí el conflicto.

Cherry-picking no es como una merge (que busca una merge-base ).

Cherry-picking toma un compromiso y aplica el cambio que introduce .

Aquí el cambio introducido es: agregar c encima de b .
Y el commit de destino no tiene ninguna b , así que para Git:

• el compromiso en sentido ascendente (destino) ha "eliminado b " (o nunca lo tuvo en primer lugar, como es el caso aquí, pero Git no lo sabe),
• el código fuente tiene una b encima de la cual se agrega c .

Por lo que Git sabe cuando intenta aplicar ese parche (y eso es todo lo que hace git cherry-pick : aplicar el parche. No busca el historial del commit de git cherry-pick ), eso es un conflicto: modificación concurrente.

Si está seguro de cómo debe ir esa resolución, puede hacerlo:

> git cherry-pick -Xtheirs dev
[master 7849e0c] dev add line c
 Date: Wed Aug 17 08:25:48 2016 +0200
 1 file changed, 2 insertions(+)

Luego, vería c agregados a la confirmación original, sin ningún conflicto (ya que indicó cómo resolverlo con la opción '' -Xtheirs '' pasada a la estrategia de fusión predeterminada recursive )

Answer 2

Técnicamente, ya que está editando la misma línea del mismo archivo en diferentes ramas, Git ve esto como un conflicto. Chypypinging, aunque no es técnicamente una operación de ''fusión'', todavía busca los mismos tipos de conflicto y le pide que los resuelva.

Para rutas en conflicto, el archivo de índice registra hasta tres versiones, como se describe en la sección "VERDADERO COMERCIO" de git-merge [1]. Los archivos del árbol de trabajo incluirán una descripción del conflicto entre los marcadores de conflicto habituales <<<<<<< y >>>>>>>.

De la Cherry-picking