Re: cherry picking and merge

On Fri, 2014-08-01 at 18:40 -0500, Nico Williams wrote:

On Fri, Aug 1, 2014 at 6:06 PM, Mike Stump [off-list ref] wrote:

quoted

On Aug 1, 2014, at 1:12 PM, Sam Vilain [off-list ref] wrote:

quoted

Git merge has a notion of discrete "merge strategies”.

quoted

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
first.
...
Nico
--

Data point:

We've been using a rebase-centric workflow for a while at my current
employer. It's simple and generally straightforward for new development
on master.

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.

Alex