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
> 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

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

Attachment: signature.asc
Description: Digital signature

Reply via email to