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

From: Elijah Newren <newren@gmail.com>
Date: Mar 20, 2019, 14:39 UTC
Message-ID: <CABPp-BEe56GFM_2g7EyXmSrULFwRAvSPBomQ66jEQmCs=HhWpg@mail.gmail.com>
In-Reply-To: <871s31vjo7.fsf@javad.com>

On Wed, Mar 20, 2019 at 8:09 AM Sergey Organov <sorganov@gmail.com> wrote:

Show 31 quoted lines

>
> Junio C Hamano <gitster@pobox.com> writes:
>
> [...]
>
> > But I do have a very strong opinion against adding yet another
> > option that takes an optional argument.  If we want to allow
> > cherry-picking a merge commit just as easy as cherrry-picking a
> > single-parent commit, "git cherry-pick -m merge" (assuming 'merge'
> > is the tip of a branch that is a merge commit) that still requires
> > the user to say "-m" is not a good improvement.  We should just
> > accept "git cherry-pick merge" without any "-m" if we want to move
> > in this direction, I would think.
>
> Let's just make '-m 1' the default option indeed. No need for further
> complexities.
>
> Exactly according to what Junio has already said before. Here:
>
> https://public-inbox.org/git/xmqqsh5gt9sm.fsf@gitster-ct.c.googlers.com
>
> Junio wrote:
>
> > Now, it appears, at least to me, that the world pretty much accepted
> > that the first-parent worldview is often very convenient and worth
> > supporting by the tool, so the next logical step might be to set
> > opts->mainline to 1 by default (and allow an explicit "-m $n" from
> > the command line to override it).  But that should happen after this
> > patch lands---it is logically a separate step, I would think.
>
> ... and as that patch already landed...

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. I would much rather they continued to get an error message and then asked other folks for help so that someone can explain to them what they should instead be doing rather than silently changing the current error into an unwanted operation. Granted, the users will at least get a confusing "Merge branch <foo>" commit message for something that isn't a merge, but I don't think the users will notice that either. It just means we've got both confusing and ugly history without the necessary individual commits or with too much having been cherry-picked. If -m 1 is too much to ask people to specify, could we provide some other shorthand? Or at least make a default-off config option people would have to set if they want a cherry-pick of a merge to succeed without specifying -m?

Elijah