git cherry-pick dice "... 38c74d es una fusión pero no se le dio la opción -m"

Hice algunos cambios en mi rama maestra y quiero llevarlos hacia arriba. cuando selecciono las siguientes confirmaciones, sin embargo, me atoro en fd9f578 donde git dice:

$ git cherry-pick fd9f578
fatal: Commit fd9f57850f6b94b7906e5bbe51a0d75bf638c74d is a merge but no -m option was given.

¿Qué está tratando de decirme git? ¿Es la elección correcta para usar aquí? La rama maestra incluye cambios en los archivos que se han modificado en la rama ascendente, por lo que estoy seguro de que habrá algunos conflictos de fusión, pero esos no son demasiado malos para solucionarlos. Sé qué cambios son necesarios y dónde.

Estas son las confirmaciones que quiero presentar.

e7d4cff added some comments...
23e6d2a moved static strings...
44cc65a incorporated test ...
40b83d5 whoops delete whitspace...
24f8a50 implemented global.c...
43651c3 cleaned up ...
068b2fe cleaned up version.c ...
fd9f578 Merge branch 'master' of ssh://extgit/git/sessions_common
4172caa cleaned up comments in sessions.c ...

La forma en que funciona una selección de cereza es tomando el diff que representa un conjunto de cambios (la diferencia entre el árbol de trabajo en ese punto y el árbol de trabajo de su padre) y aplicándolo a su rama actual.

Entonces, si un commit tiene dos o más padres, también representa dos o más diferencias: ¿cuál debe aplicarse?

Estás tratando de elegir fd9f578, lo que fue una fusión con dos padres. Por lo tanto, debe decirle al comando cherry-pick cuál contra cuál debe calcularse la diferencia, utilizando la -mopción Por ejemplo, git cherry-pick -m 1 fd9f578para usar el padre 1 como base.

No puedo decir con certeza su situación particular, pero generalmente es aconsejable usar en git mergelugar de git cherry-pick. Cuando selecciona una confirmación de fusión, contrae todos los cambios realizados en el elemento primario que no especificó -men esa confirmación . Pierdes toda su historia y engullen todas sus diferencias. Tu llamada.

-m significa el número padre.

Del git doc:

Por lo general, no puede elegir una fusión porque no sabe qué lado de la fusión debe considerarse la línea principal. Esta opción especifica el número principal (a partir de 1) de la línea principal y permite que cherry-pick reproduzca el cambio relativo al elemento primario especificado.

Por ejemplo, si su árbol de confirmación es el siguiente:

- A - D - E - F -   master
   \     /
    B - C           branch one

entonces git cherry-pick Eproducirá el problema que enfrentó.

git cherry-pick E -m 1significa usar D-E, mientras que git cherry-pick E -m 2significa usar B-C-E.

La respuesta de @ Borealid es correcta, pero suponga que no le importa preservar el historial exacto de fusión de una rama y solo quiere elegir una versión linealizada. Aquí hay una manera fácil y segura de hacerlo:

Estado de inicio: está en la sucursal Xy desea seleccionar los commits Y..Z.

1. git checkout -b tempZ Z
2. git rebase Y
3. git checkout -b newX X
4. git cherry-pick Y..tempZ
5. (Opcional) git branch -D tempZ

Lo que esto hace es crear una rama tempZbasada en Z, pero con el historial Ylinealizado en adelante, y luego seleccionarlo en una copia de Xllamado newX. (Es más seguro hacer esto en una nueva rama en lugar de mutar X). Por supuesto, puede haber conflictos en el paso 4, que tendrá que resolver de la manera habitual ( cherry-pickfunciona de manera muy similar rebasea ese respecto). Finalmente borra lo temporaltempZ rama .

Si el paso 2 muestra el mensaje "La rama actual tempZ está actualizada", entonces Y..Z ya era lineal, así que simplemente ignore ese mensaje y continúe con los pasos 3 en adelante.

Luego revise newX y vea si eso hizo lo que quería.

(Nota: esto no es lo mismo que un simple git rebase Xcuando está en la rama Z, porque no depende de ninguna manera de la relación entre Xy Y; puede haber compromisos entre el antepasado común y el Yque no desea).

Simplificar. Cherry-recoger los commits. No escojas la combinación.

Aquí hay una reescritura de la respuesta aceptada que idealmente aclara las ventajas / riesgos de los posibles enfoques:

Estás tratando de elegir fd9f578, que fue una fusión con dos padres.

En lugar de elegir una fusión, lo más simple es elegir las confirmaciones que realmente desea de cada rama de la fusión.

Como ya se ha fusionado, es probable que todas sus confirmaciones deseadas estén en su lista. Escoge cereza directamente y no necesitas meterte con la confirmación de fusión.

explicación

La forma en que funciona una selección de cereza es tomando la diferencia que representa un conjunto de cambios (la diferencia entre el árbol de trabajo en ese punto y el árbol de trabajo de su padre) y aplicando el conjunto de cambios a su rama actual.

Si un commit tiene dos o más padres, como es el caso de una fusión, ese commit también representa dos o más diferencias. El error ocurre debido a la incertidumbre sobre la cual debería aplicarse diff.

alternativas

Si determina que necesita incluir la combinación vs selección de cereza de las confirmaciones relacionadas, tiene dos opciones:

1. (Más complicado y oscuro; también descarta el historial) puede indicar qué padre debe aplicar.

   • Use la -mopción para hacerlo. Por ejemplo, git cherry-pick -m 1 fd9f578usará el primer padre que aparece en la fusión como base.

   • También tenga en cuenta que cuando selecciona una confirmación de fusión, contrae todos los cambios realizados en el elemento primario que no especificó -men esa confirmación . Pierdes toda su historia y engullen todas sus diferencias. Tu llamada.

2. (Más simple y más familiar; conserva el historial) que puede usar en git mergelugar de git cherry-pick.

   • Como es habitual git merge, intentará aplicar todas las confirmaciones que existen en la rama que está fusionando, y enumerarlas individualmente en su registro de git.

Simplificación del método @Daira Hopwood bueno para elegir una sola confirmación. No necesita ramas temporales.

En el caso del autor:

• Se quiere confirmar Z (fd9f578)
• Y es comprometerse antes
• X rama de trabajo actual

entonces hazlo:

git checkout Z   # move HEAD to wanted commit
git reset Y      # have Z as changes in working tree
git stash        # save Z in stash
git checkout X   # return to working branch
git stash pop    # apply Z to current branch
git commit -a    # do commit