W dniu 2014-08-01 04:43, brian m. carlson pisze:
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.
Note that you should try to avoid cherry-picking, as they do not leave trace in the graph of revisions. For example if you are creating a bugfix, instead of putting it directly on maint, and then cherry-picking to master, it is better to create a separate feature branch for this fix (based at an early version), and then merge said branch into maint, then into master. It is described in blog post by Junio Hamano (which I cannot find now).
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.
There is also git-imerge, third party tool that is intended to help merging changes (and make it possible to do it in incremental way). HTH -- Jakub Narębski -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
