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

[Sergey Organov <sorganov@gmail.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Elijah Newren <newren@gmail.com> writes:
>>
>>> 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.
>>
>> We can just reject this RFC patch and we'd be in a slightly safer
>> place.  You still need to tell us with "-m 1" on the command line
>> that you are picking a range with merges in it.  But then I am sure
>> that clueless people blindly would alias "pick = cherry-pick -m1" and
>> use "git pick" and blindly pick ranges here and there, so I am not
>> sure such a slightly-more safety buys us very much.
>
> To put it a bit differently, I share with you that picking merges
> should be deliberate and it is safer to make sure allowing it only
> when the told us that s/he knows the commit being picked is a merge,

Something like "--[no-]ban-merges" then [*], having "--ban-merges" as
default?

> but when we started allowing "-m 1" for non-merge commits in the
> current world where cherry-pick can work on a range, the ship has
> already sailed.

Except that it could be a different ship, provided we've got
"--ban-merges". Having "-m 1" as default stops to be an issue, and
explicit "-m 1" could then imply --no-ban-merges, that could be in turn
overwritten by explicit "--ban-merges", if necessary.

[*] "--[no]-merges" won't do, as one would expect merges to be silently
dropped from a range of cherry-picks, similar to what "git log" or "git
rev-list" does. BTW, is it a good idea for cherry-pick to start to use
"git rev-list" and support all the options available there?

-- Sergey