From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 23 Mar 2015 01:25:07 GMT
Subject: Re: [PATCH 1/5] Add a new option 'merges' to revision.c
Message-ID: <xmqqegogbj4c.fsf@gitster.dls.corp.google.com>
In-Reply-To: <550F6175.9050606@posteo.de>

Koosha Khajehmoogahi <koosha@posteo.de> writes:

>>>  	} else if (!strcmp(arg, "--merges")) {
>>> +		revs->max_parents = -1;
>>>  		revs->min_parents = 2;
>> 
>> But is this change warranted?  An existing user who is not at all
>> interested in the new --merges= option may be relying on the fact
>> that "--merges" does not affect the value of max_parents and she can
>> say "log --max-parents=2 --merges" to see only the two-way merges,
>> for example.  This change just broke her, and I do not see why it is
>> a good thing.
>
> The point is that if you have your log.merges conf option set to 'hide'
> and you use git log --merges (two mutually conflicting options),
> git will silently exit without anything to show.

That is not an excuse to break "--merges" and "--no-merges" for
existing users who do not care about setting log.merges option to
anything.

The whole point of introducing a new "--merges=show" option was so
that people can sanely countermand log.merges configuration from the
command line without breaking --merges and --no-merges, wasn't it?