Re: cherry picking and merge
On Aug 1, 2014, at 9:27 AM, Jakub Narębski <jnareb@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.