Re: cherry picking and merge

[Jonathan Nieder <jrnieder@gmail.com>]

Hi Mike,

Mike Stump wrote:

> Cherry picking doesn’t work as well as it should.  I was testing on
> git version 1.7.9.5.
>
> Put in a line in a file, call it:
>
> first version
>
> then cherry pick this into your branch. Then update on master and
> transform that into:
>
> second version
>
> then, merge that branch back to master.  Death in the form of conflicts.

Do you mean that "git merge" should be aware of what changes you have
already cherry-picked?

It isn't, and that's deliberate ("git merge" is designed to be simple
as possible, though no more simple than that).  This way, if on a side
branch someone makes a change that would conflict with "master" and
then backs it out, then the branch can still merge cleanly.

Generally people do one of the following:

 * Use a merge-centric workflow.  Don't cherry-pick "forward" but
   merge instead.  (Do use cherry-pick for backports when you forgot
   to commit a fix on top of the oldest supported branch that would
   need it.)  The gitworkflows(7) manpage has more details on how
   this works.

 * Use a cherry-pick-centric workflow.  Never merge.  Notice when
   you're trying to apply a patch you already applied and skip it.
   (Others in the thread have covered this workflow a little.)

Even in those workflows, it's possible to have conflicts due to
genuinely conflicting changes, even with no cherry-pick involved.  I
find the '[merge] conflictstyle = diff3' setting (see git-config(1))
and git-rerere(1) to be helpful in making that less painful.

Hope that helps,
Jonathan