Elijah Newren <new...@gmail.com> 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. There are lots of folks at $DAYJOB that > cherry-pick things, not all of them are expert git-users, and I am > certain several have erroneously attempted to cherry-pick merges > before.
It was a lot simpler back when "git cherry-pick" did not accept ranges. You are either knowingly cherry-picking a merge, or doing so by mistake, and because the command rejected cherry-picking a merge without being told with "-m $n" which parent the mainline is by default, we are assured that the user knew that s/he was picking a merge commit when we saw "-m $n". It's not so simple in the world after we started allowing picks of a range. "cherry-pick -m1 A..B" did not work when the range A..B is a mixture of merges and non-merges (which is the case 100% of the time), as the command used to error out when given the -m option for a single-parent commit. Earlier we said that "as long as the $n does not exceed the number of actual parents, let's allow '-m $n' even for non-merge commits." to fix it. 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.
