On Aug 1, 2014, at 9:27 AM, Jakub Narębski <jna...@gmail.com> wrote: > > Note that you should try to avoid cherry-picking, as they do not > leave trace in the graph of revisions.
Fine, then I want a new command to merge in a change into my branch from another branch and I want merge to account for the motion and not duplicate it when I merge that branch back into master. Funny thing is, cherry and merge seem to be documented mostly to do exactly what I want. > 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 You’re assuming that I’m the author of master, I’m not, I’m merely a contributor. This tail doesn’t wag that dog. What that means is that I cannot change the world to work around a simple bug in git. > 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). Then remove git merge and replace it with git-imerge. :-) Anyway, I read that, and I can see some beauty of that that might be nice in complex merges. The problem is, I want git merge to work. I was curious if svn handles this better the same or worse, and it did it just fine. I know that a while ago, svn could not handle this, it would do what git does currently. Apparently they figured out it was a bug and fixed it. Have you guys figured out it is a bug yet? The first step in solving a problem, is admitting you have a problem.-- 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
