Re: [RFC PATCH] cherry-pick: set default `--mainline` parent to 1

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 21, 2019, 02:17 UTC
Message-ID: <xmqqd0mlt1h1.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CABPp-BEe56GFM_2g7EyXmSrULFwRAvSPBomQ66jEQmCs=HhWpg@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 6 quoted lines

> 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.