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

[Sergey Organov <sorganov@gmail.com>]

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

> Sergey Organov <sorganov@gmail.com> writes:
>
>>> With it reverted, "[alias] cp = cherry-pick -m1" can be used to train
>>> the user to blindly pick a range that has a merge without thinking,
>>> which is what I meant by "ship has already sailed".
>>
>> Did you mean "With it *not* reverted" here?
>
> Thanks for a correction.  Yes, if we do not revert it, then that
> would allow people to follow a bad workflow we do not want to
> recommend (and I think that is what Elijah does not want to do), and
> that is why I said the ship has already sailed.

I still don't think it makes sense to revert the patch (that fixed a
real-life issue) on the sole ground that, as a side-effect, it has
provided an opportunity that could potentially be abused, specifically
by defining a random alias, and then shooting oneself in the foot with
it. And even then no irreversible damage actually happens.

Moreover, if somebody actually wants to "follow a bad workflow", he
still needs to ask for it explicitly, either by providing '-m 1', or by
defining and using an alias, so let him do it please, maybe he even does
know what he is doing, after all.

>
>> Those who don't like such alias are still free not to define or use it.
>
> That's not the point.  Those who do want to be careful can learn to
> use a new option --forbid-stupid-things, but why should they?

Sure thing, who said they should? Fortunately, that's exactly the
current state, no need to invent and specify any --forbid-stupid-things
option, and even if we pretend the option is already there and is
active by default, still no need to revert anything.

> They should be forbidden from doing stupid things by default, which is
> the point of this exchange.

I already agreed before to assume this, and it seems that we now all
agree this safety should be preserved, as there are those who actually
care. However, as merges are already forbidden right now with all the
current defaults, I fail to see how it could justify reverting of
already applied patch.

To me, the actual question here is: what's the option that overrides
that default? The current answer is: "-m 1", that admittedly is not very
nice, but has not been introduced by any of the recent patches, so is
not solvable by reverting any of them.

To summarize, as it looks to me, it's mostly the current way of allowing
merges, that cryptically reads as "-m 1", that makes the OP unhappy.
This was already the case before the "allow '-m 1' for non-merge
commits" patch, so reverting it won't solve the problem in any suitable
way.

Due to all the above, may we please finally let alone the already
applied patch and focus on finding (or denying) actual solution to the
original issue of this thread?

If so, I'm still on the ground of providing new, say,
"--no-forbid-merges" option, if anything. I'm with Duy Nguyen that the
way suggested by RFC, making value optional for yet another short
option, is to be avoided at all costs.

-- Sergey