From: Mike Stump Date: Fri, 01 Aug 2014 23:06:10 GMT Subject: Re: cherry picking and merge Message-ID: <4E372CD5-33CA-4AF5-8647-F6BBC64BABA8@comcast.net> In-Reply-To: <53DBF4C9.2090905@vilain.net> On Aug 1, 2014, at 1:12 PM, Sam Vilain 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.