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
Attachment:
signature.asc
Description: Digital signature