From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 11 Mar 2026 17:18:33 GMT
Subject: Re: [PATCH v7 4/5] format-patch: add commitListFormat config
Message-ID: <xmqqa4weqo7q.fsf@gitster.g>
In-Reply-To: <3fb4baf7-a820-401d-815b-a0b7c11fe6c3@gmail.com>

Phillip Wood <phillip.wood123@gmail.com> writes:

> On 10/03/2026 16:45, Junio C Hamano wrote:
>> Phillip Wood <phillip.wood123@gmail.com> writes:
>> 
>>>> Possible values:
>>>>     - commitListFormat is set but no string is passed: it will default to
>>>>       "[%(count)/%(total)] %s"
>>>
>>> It is unusual for an empty config value to mean something different from
>>> it not being set. The reason for this is that it allows
>>>
>>>       git -c config.key some-command
>>>
>>> to act as though config.key was not set.
>> 
>> That syntax is the same as setting config.key=true; disabling the
>> feature triggered by config.key is quite counter-intuitive, isn't
>> it?
>
> I'd forgotten about the boolean case, I was thinking about an empty or 
> missing value clearing multi-valued keys which is quite common I think. 

Yes, "git -c config.list= -c config.list=one -c config.list=two cmd"
would defeat list-valued config.list defined in /etc/gitconfig and
~/.gitconfig and then use a list with only "one" and "two" on it.
Configuration variables like push.pushOption, merge.suppressDest,
remote.<name>.url, etc. all use this convention.

The form without '=' is a valueless true that I do not think is used
for such "clear the list", though.