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

[Sergey Organov <sorganov@gmail.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Sergey Organov <sorganov@gmail.com> writes:
>
>>> The same effect can be had by just reverting "let's allow -m1 for
>>> single-parent commit", can't it?  That is a far simpler solution, I
>>> would say.
>>
>> Those one didn't introduce the issue currently at hand, as we still
>> don't allow merges by default, so why do we need to rewind it?
>
> With it reverted, "[alias] cp = cherry-pick -m1" can be used to train
> the user to blindly pick a range that has a merge without thinking,
> which is what I meant by "ship has already sailed".

Did you mean "With it *not* reverted" here? Because with it reverted,
"cherry-pick -m1" will rather loudly fail on the first non-merge commit
in the range. Such alias would be useless without that patch.

Those who don't like such alias are still free not to define or use it.

> With it reverted, a range pick of a straight single strand of pearls
> would still work just fine.  And the user is forced to think and
> chop a range with a merge into a set of subranges each of which is a
> single strand of pearls, plus picking individual merges (if picking
> these merges is really what the user wants, that is).

Unfortunately, this gets us back to the exact problem with practical
use-case the patch was provoked by. There was a large number of commits
to be picked, and the set has been carefully built by "git rev-list" (as
"git cherry-pick" built-in features were not enough: yet another issue).
Some of these commits were merges, and handling all this manually (and
repeatedly) would be a real pain. It was easier to locally patch "git
cherry-pick -m1" to achieve the goal. Then I thought that it could help
others in the future, and then took time to provide the patch. It'd be
a real pity to get back to where I started.

BTW, the above also shows that the issue with "-m 1" existed even before
"git cherry-pick" started to accept ranges, as I was not using these
ranges anyway.

Overall, I mean that I still need a way to tell "git cherry-pick" that I
do know what I'm doing, so that it stops complaining on a non-issue.
Thus if the patch is reverted, a new option should be added just for
this goal, -- back to where we are now, but an option already added.

> As ensuring the users to think is the whole point of excercise,

Yeah, provided they do have a suitable way out. Without that patch,
there was none.

> the original system before we allowed "-m1" for single parent commit
> was after all giving us the right balance, I guess, without having to
> add yet another new option.

No, unfortunately it didn't, and to me the patch in question still seems
to be in the right direction, legitimate, and useful.

Moreover, I still can't see how it's harmful. Just don't use '-m 1' if
you don't want merges.

-- Sergey