Junio C Hamano <gitster@xxxxxxxxx> writes: > Sergey Organov <sorganov@xxxxxxxxx> 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. To clarify further my short answer: S> Those one didn't introduce the issue currently at hand, as we still S> don't allow merges by default, so why do we need to rewind it? The "let's allow -m1 for single-parent commit" even doesn't affect merge commits at all, so I fail to see how reverting it may help to resolve the issue that C.J. wants to solve with his proposed patch. If we want to disallow picking merges by default, it's already so right now, no reverts or patches required. Then, as I see it, it's the current way of allowing merges, that cryptically reads as "-m 1", that makes the OP unhappy. This problem was already there before the aforementioned patch, so reverting the patch won't solve it. OTOH, it's exactly this problem that "--[no]-ban-merges" would solve. Finally, "--[no-]ban-merges" would allow to easily make "-m 1" the default later, as a separate change, should we decide it's the right thing to do. -- Sergey
