Re: [RFC PATCH] cherry-pick: set default `--mainline` parent to 1

[Sergey Organov <sorganov@gmail.com>]

Elijah Newren <newren@gmail.com> writes:

> On Wed, Mar 20, 2019 at 8:09 AM Sergey Organov <sorganov@gmail.com> wrote:
>>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>> [...]
>>
>> > But I do have a very strong opinion against adding yet another
>> > option that takes an optional argument.  If we want to allow
>> > cherry-picking a merge commit just as easy as cherrry-picking a
>> > single-parent commit, "git cherry-pick -m merge" (assuming 'merge'
>> > is the tip of a branch that is a merge commit) that still requires
>> > the user to say "-m" is not a good improvement.  We should just
>> > accept "git cherry-pick merge" without any "-m" if we want to move
>> > in this direction, I would think.
>>
>> Let's just make '-m 1' the default option indeed. No need for further
>> complexities.
>>
>> Exactly according to what Junio has already said before. Here:
>>
>> https://public-inbox.org/git/xmqqsh5gt9sm.fsf@gitster-ct.c.googlers.com
>>
>> Junio wrote:
>>
>> > Now, it appears, at least to me, that the world pretty much accepted
>> > that the first-parent worldview is often very convenient and worth
>> > supporting by the tool, so the next logical step might be to set
>> > opts->mainline to 1 by default (and allow an explicit "-m $n" from
>> > the command line to override it).  But that should happen after this
>> > patch lands---it is logically a separate step, I would think.
>>
>> ... and as that patch already landed...
>
> This worries me that it'll lead to bad surprises.  Perhaps some folks
> cherry-pick merges around intentionally, but I would want that to be a
> rare occurrence at most.  There are lots of folks at $DAYJOB that
> cherry-pick things, not all of them are expert git-users, and I am
> certain several have erroneously attempted to cherry-pick merges
> before.

Wow, random Joes cherry-picking here and there... Sounds like a bigger
problem is lurking here.

> I would much rather they continued to get an error message
> and then asked other folks for help so that someone can explain to
> them what they should instead be doing rather than silently changing
> the current error into an unwanted operation.  Granted, the users will
> at least get a confusing "Merge branch <foo>" commit message for
> something that isn't a merge, but I don't think the users will notice
> that either.  It just means we've got both confusing and ugly history
> without the necessary individual commits or with too much having been
> cherry-picked.

To me it seems that cherry-picking wrong commit is cherry-picking wrong
commit, no matter if it's a merge or not. I don't think that trying to
save a user from such a mistake worth the trouble, given that
cherry-pick is reversible operation, but I still see your point.

> If -m 1 is too much to ask people to specify, could we provide some
> other shorthand? Or at least make a default-off config option people
> would have to set if they want a cherry-pick of a merge to succeed
> without specifying -m?

If we decide we still need this safety precaution, I'd opt to continue
to require '-m 1' to cherry-pick a merge, rather than adding some
special support. Not such a big deal.

BTW, doesn't git have generic configuration support to add default
option to a command, I wonder (I'm aware of aliases, but they don't
seem to fit)? The C.J. then would simply add '-m 1' to 'cherry-pick' in
configuration. No luck?

-- Sergey