Es git cherry-pick en realidad lo mismo que git show + git apply?

Será que

git cherry-pick <rev> 

de hecho es exactamente lo mismo que

 git show <rev> | git apply -3 - 

???

Como ejecutar cualquiera de los dos produce exactamente el mismo resultado para mí, y si supiera que son equivalentes, podría entender mucho mejor cómo funciona Cherry Pick con GIT, ya que no siempre me da el resultado que obtuve. esperar, pero eso es probablemente porque el único cambio no se puede aplicar y la recolección de cerebros vuelve a una fusión tripartita (eso es lo que hace -3 en el segundo command) y eso explicaría el resultado inesperado.

Además de la respuesta de Edmundo , que es correcta y la he modificado, hay muchos otros detalles molestos, incluido el comentario de ephemient sobre files binarys (las necesidades de git show --binary para producir un parche binary) y que puede necesitar --full-index también, en algunos casos raros donde una línea Index: abreviada es insuficiente. 1

Además, por supuesto, git apply (con o sin -3 ) no le importa un índice sucio y un tree de trabajo, mientras que git cherry-pick requiere un índice limpio y un tree de trabajo, a less que agregue -n . Y, si omites -n , git cherry-pick continúa para realizar una confirmación, lo que git apply nunca ocurre.

Todo lo dicho, sin embargo, sí, estos dos deberían ser funcionalmente equivalentes para los casos normales.


1 Para que esto ocurra, los hashes de blob deben ser no exclusivos con la abreviatura. Esto se hizo de forma automática y correcta en Git versión 1.7.2, aunque si fuerza una longitud de abreviatura particular con core.abbrev o un indicador de línea de command, aún puede get abreviaciones de hash no únicas. Agregar --full-index garantiza que obtenga los únicos.

(Si tuviera que save un diff por un período prolongado, agregue un montón de objects nuevos al repository, y luego intente git apply -3 el diff; es posible que el Index: abreviado Index: líneas que no eran ambiguas antes se vuelvan ambiguas ahora. )

Técnicamente hablando, git cherry-pick funciona como una combinación de git donde, en lugar de search la "mejor revisión que está presente en ambas twigs" para verificar las diferencias y fusionarlas , la "revisión común" para la lógica de fusión está obligada a ser el padre de la revisión que está seleccionando.