Re: [PATCH v2 2/5] log: honor log.merges= option

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 13, 2015, 04:56 UTC
Message-ID: <xmqqoams4oed.fsf@gitster.dls.corp.google.com>
In-Reply-To: <5525062A.2010905@posteo.de>

Koosha Khajehmoogahi <koosha@posteo.de> writes:

Show 11 quoted lines

> On 04/08/2015 04:28 AM, Junio C Hamano wrote:
>
>> It is strange that you have to ask me to give you the reason why you
>> chose it that way, isn't it?
>
> AFAIK, the only other command that supports --merges and --no-merges options is
> rev-list. This new feature aims to make a default behavior for the commands
> that have these options. The command-line option is supported by the two commands.
> However, the config var is only used by git-log and rev-list ignores it. I didn't
> exclude rev-list for any particular reason. If we need, I could also handle it in
> rev-list.

As rev-list is plumbing, it shouldn't be affected by the UI level customization knobs like this one; otherwise you will break people's scripts when end users choose to use the new knobs.

Historically, "whatchanged" has been the way to ask for "log", with different default output format (but not different commit selection logic). I would think people who are used to "whatchanged" would expect that the command would pay attention to what "log" would.

As I already mentioned with the reason why, I do not think "show" and "format-patch" should pay attention to it.

There may be other commands from the "log" family (i.e. what is defined in builtin/log.c and/or uses get_revision() API to walk the commit graph), for which similar reasoning should be done to decide if each of them should or should not pay attention to it.

Thanks.