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

["C.J. Jameson" <cjcjameson@gmail.com>]

Thank you everyone for the comments!

Confirming Sergey's summary: at this point, I think my only residual
opinion is that requiring `-m 1` or `--mainline 1` is a little cryptic
for someone who's just cherry-picking a single commit, which happens
to be a merge commit. `--no-forbid-merges` would be the thorough way
of accommodating it, but it's even more verbose and you'd still need
to discover it...

I'd be fine abandon this -- thanks again!

C.J.

On Fri, Mar 22, 2019 at 8:22 AM Sergey Organov <sorganov@gmail.com> wrote:
>
> 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