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

> Sergey Organov <sorga...@gmail.com> writes:
>
>>> 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.
>
> The same effect can be had by just reverting "let's allow -m1 for
> single-parent commit", can't it?  That is a far simpler solution, I
> would say.

Those one didn't introduce the issue currently at hand, as we still
don't allow merges by default, so why do we need to rewind it?

-- Sergey

Reply via email to