Re: cherry picking and merge

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Aug 1, 2014, 20:02 UTC
Message-ID: <20140801200201.GS12427@google.com>
In-Reply-To: <51C01AAA-3CFB-4110-BAE9-7D04CA8EE53A@comcast.net>

Hi Mike,

Mike Stump wrote:

Show 13 quoted lines

> 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