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

Koosha Khajehmoogahi [off-list ref] writes:

On 04/08/2015 04:28 AM, Junio C Hamano wrote:

quoted

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.