Hi Junio,
On Thu, 21 Mar 2019, Junio C Hamano wrote:
> 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. 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".
Indeed.
> 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.
It gets even better.
Recently, I found myself wishing for the equivalent of `--rebase-merges`
in `git cherry-pick`. In other words, I wanted to transplant some commits
(including merge commits) from a different branch onto the current branch.
Currently, I work around this by this kind of dance:
$ git checkout B^0
$ git rebase -ir --onto HEAD@{1} A
$ git checkout @{-1}
$ git merge --ff-only HEAD@{1}
which does work, but it changes the worktree quite a bit (often causing
complete rebuilds due to "changed" header files, when those rebuilds were
not actually necessary).
It also has the rather real downside of not mixing well with an
already-running rebase...
And with that use case in mind, I think that making the `-m 1` option the
default is even less desirable than I thought before.
Ciao,
Dscho
