Re: [PATCH v2 0/7] making log --first-parent imply -m

[Sergey Organov <sorganov@gmail.com>]

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

> Sergey Organov <sorganov@gmail.com> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> Sergey Organov <sorganov@gmail.com> writes:
>>>
>>>> Sounds great, I only hoped we can do it right now, with this new
>>>> --diff-merges option, maybe as a pre-requisite to the patches in
>>>> question, but Jeff said it's too late, dunno why.
>>>
>>> A follow-up patch or two to remove the "--diff-merges" option and
>>> add the "--diff-parents=(none|<number>|c|cc|all)" option on top of
>>> the jk/log-fp-implies-m topic BEFORE it graduates to 'master' is a
>>> possibility.
>>>
>>> But is it worth the delay?  I dunno.
>>
>> I don't think it's worth the delay, provided yet another new
>> --diff-parents is to be implemented rather that using --diff-merges for
>> that.
>
> I was responding to your "it's too late, dunno why", as you seemed
> not to want to waste an option "--diff-merges" that will become
> unused when "--diff-parents" come and also wanted it to happen right
> now.  If you no longer want to see it happen right now, that's OK by
> me.

Eh, no, as I see it, I suggested to have

  --diff-merges=(none|<number>|c|cc|all)

right now rather than introduce yet another option (--diff-parents)
later, as well as to make --first-parent imply --diff-merges=1 rather
than "-m" (the latter in turn being synonym for --diff-merges=all), and
I thought that's what was rejected by Jeff on the ground that it's too
late, but as he clarified in his recent response it was not.

I mean, why introduce --[no-]diff-merges in the first place, if we do
agree --xxx=(none|...) is where we'd like to end up? I thought the
answer was "it's too late", but in fact it was an answer to changing
semantics of -m that I don't think I suggest.

As a side-note, my secret hope is for pure "git log -p" to give me diff
against first parent for all the commits, no matter how many parents
they happen to have. This desire still sounds like a job for
configuration option though, rather than, or in addition to,
--diff-merges or --diff-parents? We well can later introduce a
config to assume --diff-merges=<config> when no explicit
--diff-merges=<value> is specified, right?

Thanks,
-- Sergey