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

Reply via email to