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@xxxxxxxxx> wrote: > > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > Sergey Organov <sorganov@xxxxxxxxx> 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
