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
