Junio C Hamano <gitster@xxxxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Elijah Newren <newren@xxxxxxxxx> writes: >> >>> This worries me that it'll lead to bad surprises. Perhaps some folks >>> cherry-pick merges around intentionally, but I would want that to be a >>> rare occurrence at most. >> >> We can just reject this RFC patch and we'd be in a slightly safer >> place. You still need to tell us with "-m 1" on the command line >> that you are picking a range with merges in it. But then I am sure >> that clueless people blindly would alias "pick = cherry-pick -m1" and >> use "git pick" and blindly pick ranges here and there, so I am not >> sure such a slightly-more safety buys us very much. > > 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. [*] "--[no]-merges" won't do, as one would expect merges to be silently dropped from a range of cherry-picks, similar to what "git log" or "git rev-list" does. BTW, is it a good idea for cherry-pick to start to use "git rev-list" and support all the options available there? -- Sergey
