On Aug 1, 2014, at 1:12 PM, Sam Vilain <s...@vilain.net> wrote:
> Git merge has a notion of discrete "merge strategies”.

> There's no particular reason that you couldn't implement a merge
> strategy which works more like SVN's approach, which essentially does an
> internal rebase and then commits the result.

Well, being a simple user, wanting to do a simple thing, I want the default 
strategy to just work.  The expert that wants it to work faster, but less well, 
well, they can use a merge -s faster, or cherry-pick -s faster.

> However, there are corresponding disadvantages to this strategy.  It's
> just as easy to contrive a situation where this "internal rebasing"
> doesn't do the right thing, even without cheating by getting the
> metadata wrong.

I sketched a solution using branches…  A large portion of the failures that 
happen when a cherry is remerged are gone.  I feel that benefit easily swamps 
the problem you sketched.

> And besides, there's already a way to do this: do an actual rebase.

One problem is that rebase doesn’t work with co-workers nicely…  The other is 
that it isn’t spelled merge.  I am a simple user.

>> 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.
> So, I have to chuckle when I read this indignant comment.

:-)  Yeah, a chuckle, good.  Actually, no anger is involved.  I’d just like for 
git to work better in this regard.--
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