Re: cherry picking and merge

From: Nico Williams <nico@cryptonector.com>
Date: Aug 1, 2014, 23:40 UTC
Message-ID: <CAK3OfOiG8kzKYRUGZJW90t-DyjWf775MfMDxzin0gw94ATS7nw@mail.gmail.com>
In-Reply-To: <4E372CD5-33CA-4AF5-8647-F6BBC64BABA8@comcast.net>

On Fri, Aug 1, 2014 at 6:06 PM, Mike Stump <mikestump@comcast.net> wrote:

Show 8 quoted lines

> On Aug 1, 2014, at 1:12 PM, Sam Vilain <sam@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.

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.

My workflow is rebase-heavy. It's long been so, and it was so before git happened. The only case where I can imagine not using a rebase-heavy workflow is where I have to track multiple forked upstreams and so I want to merge each into my branch.

If tracking multiple forked upstreams is not your case and yet rebase can't work for you then I'd like to understand why. Please help me understand your use case. OTOH, if your use case is amenable to rebase, then I highly recommend that you try it.

(I find that many users are allergic to rebasing. Many people have told me that rebase is lying, that history must be immutable, and so on, all ignoring that: git users don't rebase published branches, and that other VCSes tend to squash (therefore lose) history anyways when pushing merges upstream. But this all seems theological rather than rational. It's true that I dislike merge commits, but that's a different story; I'm not allergic to merging after all.)

Nico --