Subject: Re: [PATCH v7 4/5] format-patch: add commitListFormat config

From: Junio C Hamano <[email-masked]>
Date: Wed, 11 Mar 2026 10:18:33 -0700

Phillip Wood <[email-masked]> writes:

> On 10/03/2026 16:45, Junio C Hamano wrote:
>> Phillip Wood <[email-masked]> 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.