git-cherry parece no funcionar para fusiones desorderadas

Traté de usar git cherry-pick para fusionar algunas confirmaciones de master y luego de git-cherry para determinar qué commits se fusionaron actualmente. Funciona bien mientras lo fusiono en el order en que está en master, pero cuando omito la fusión de uno de los commits no me muestra el siguiente fusionado. Ejemplo a continuación:

$ git branch * branch master $ git log --oneline 46aad17 comment4 56e43b0 comment3 26370b3 comment2 6192fa4 comment1 $ git cherry -v branch master - 5c5e979707cd6a77ef3ae79627cdd211cad86a28 comment3 - ee0386c78d9e6d21dce7a8bac8e40beef73fb993 comment4 + 9495c94ece440d9a05c3218f88d1b72a7fd67664 unmerged # this wasn't merged + 235b0822f08f351264071e7b2500caa9af997fb8 comment2 

La pregunta es ¿por qué comment2 se muestra como no fusionada mientras se muestra fusionada en log?

Solo como una nota preliminar, es un poco confuso describir esto como fusiones: son solo selects de cereza, es decir, confirmaciones creadas al aplicar el parche introducido por otra confirmación a un nuevo padre.

git cherry observa el parche que introduce un commit y testing para ver si ya hay un parche similar que se haya introducido en la twig upstream. Como se documenta en la página man de git cherry , decide si dos parches son iguales en function de si tienen el mismo "ID de parche" , que se describe como:

Un "ID de parche" no es más que un SHA1 de la diferencia asociada con un parche, con numbers en blanco y línea ignorados. Como tal, es "razonablemente estable", pero al mismo time también razonablemente único, es decir, dos parches que tienen el mismo "ID de parche" casi garantizan que sean lo mismo.

IOW, puede usar esto para search probables commits duplicates.

Por lo tanto, sospecho que si la confirmación asociada con comment2 no se detecta como que ya se ha aplicado, es porque los ID de los parches son diferentes. Eso podría ser, por ejemplo, porque tuvo que resolver un conflicto cuando seleccionó el commit asociado con comment2 . Eso bien podría significar que los parches que presentaron los commits terminaron siendo diferentes. Puede ver si eso es correcto al comparar el resultado de estos dos commands:

 git show 26370b3 git show 235b082