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

From: Sergey Organov <sorganov@gmail.com>
Date: Mar 21, 2019, 11:59 UTC
Message-ID: <87k1gsh1zs.fsf@javad.com>
In-Reply-To: <xmqqbm24sk68.fsf@gitster-ct.c.googlers.com>

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

Show 12 quoted lines

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

Show 5 quoted lines

> 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