Re: cherry picking and merge

On Thu, Jul 31, 2014 at 05:58:17PM -0700, 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.

In gcc land, I do this sort of thing all the time, and I need a
merging subsystem to actually keep track of things.  I can manage this
will diff and patch and it works flawlessly.  The point of using
something better than diff and patch is for it to be better than diff
and patch.

I’d like for merge to merge in the work that has yet to be merged.
Not that, plus blindly try and apply or reapply cherry picked items.

You're not the first person to be surprised by the way merge works.
From the git-merge manpage:

  [This behavior] occurs because only the heads and the merge base are
  considered when performing a merge, not the individual commits.

(That was added after 1.7.9.5.)

If you want the behavior of applying multiple patches in a row, you want
to use git rebase, not git merge.  Since rebase re-applies the patches
of each of your commits on top of another branch, the identical change
won't cause conflicts.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187