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