Elijah Newren [off-list ref] 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.