Re: [PATCH] cherry-pick: do not error on non-merge commits when '-m 1' is specified

[Sergey Organov <sorganov@gmail.com>]

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

> Sergey Organov <sorganov@gmail.com> writes:
>
>> When cherry-picking multiple commits, it's impossible to have both
>> merge- and non-merge commits on the same command-line. Not specifying
>> '-m 1' results in cherry-pick refusing to handle merge commits, while
>> specifying '-m 1' fails on non-merge commits.
>>
>> This patch allows '-m 1' for non-merge commits. Besides, as mainline is
>> always the only parent for a non-merge commit, it made little sense to
>> disable it in the first place.
>
> In the original context to pick a single commit, it made perfect
> sense to avoid mistakes by blindly passing '-m 1' to non-merge
> commit.
>
> It may be fair to say that we failed to reconsider what to
> do with '-m 1' when we did 7e2bfd3f, but it is utterly an unfair 
> history revisionism to say that it made little sense to disable it
> in the first place.

In fact I had zero intention on any revisionism. Now I see I should have
said "makes little sense" in present tense to avoid touching deep
historical issues, sorry!

Something like:

"This patch allows '-m 1' for non-merge commits. As mainline is always
the only parent for a non-merge commit, it makes little sense to disable
it."

sounds OK?

>
> The change to the code itself looks sane, but applying this patch
> alone will break existing tests whose expectations must be updated,
> and this new behaviour must be protected by a new test (or two) so
> that we won't accidentally stop accepting "-m 1" for a single-parent
> commit.

I fixed most of the tests, but

"t3510/4: cherry-pick persists opts correctly"

is an offender for me. It looks like it [ab]uses current "-m 1" behavior
just to stop in the middle of the sequence, and I'm not sure how to fix
it most suitably.

Thanks!

-- 
Sergey