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

>
> Elijah Newren <newren@gmail.com> writes:
>
> > On Wed, Mar 20, 2019 at 8:09 AM Sergey Organov <sorganov@gmail.com> wrote:
> >>
> >> 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.
>
> Wow, random Joes cherry-picking here and there... Sounds like a bigger
> problem is lurking here.

>
> > 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.
>
> To me it seems that cherry-picking wrong commit is cherry-picking wrong
> commit, no matter if it's a merge or not. I don't think that trying to
> save a user from such a mistake worth the trouble, given that
> cherry-pick is reversible operation, but I still see your point.
>

> > 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?
>
> If we decide we still need this safety precaution, I'd opt to continue
> to require '-m 1' to cherry-pick a merge, rather than adding some
> special support. Not such a big deal.
>
> BTW, doesn't git have generic configuration support to add default
> option to a command, I wonder (I'm aware of aliases, but they don't
> seem to fit)? The C.J. then would simply add '-m 1' to 'cherry-pick' in
> configuration. No luck?
>