On Fri, 2014-08-01 at 18:40 -0500, Nico Williams wrote:
> On Fri, Aug 1, 2014 at 6:06 PM, Mike Stump <mikest...@comcast.net> wrote:
> > 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. [...]
> Different users want different defaults. You can't always have the
> one you want.
Or to put it another way: one man's bug is another man's feature.
> As for rebase, I still don't understand why it doesn't work for you.
> You didn't really explain. Suppose we're right and it's the right
> solution for you, then you might be ecstatic, but you gotta try it
We've been using a rebase-centric workflow for a while at my current
employer. It's simple and generally straightforward for new development
However we need to maintain multiple 'released' version branches which
receive hotfixes and (sadly) features from later development, and merges
make it much easier to visualise which releases have received specific
fixes/shinies than cherry-picks do.
In a hybrid merge/rebase workflow it is convenient to have the option of
merges which yield rebase-like output. We have seen awkward merges
outside of master, but I mostly see that as an indication that we
shouldn't be mixing workflows so much, ie. hotfixing one thing with a
cherry-pick and another with a merge (usually only happens when the
branch predates our use of merges).
TL;DR: The option of a rebase-like merge would be a nice feature, but
the default system does not seem so onerous.
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