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

[Junio C Hamano <gitster@pobox.com>]

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

>>> Perhaps "format.commitlistformat = false" should disable the modern
>>> format and fall back to "shortlog", setting it to true (including
>>> the use of "valueless true" syntax) should enable it and use the
>>> modern default "log:[%c/%t] %s" format, and non-bool text should be
>>> used as a custom specification ("shortlog", or "log:<format>")?
>>>
>>> I.e.
>>>
>>> 	switch (git_parse_maybe_bool_text(value)) {
>>>          case 0: /* false */
>>> 		fmt_cover_letter_commit_list = "shortlog";
>>> 		break;
>>> 	case 1: /* true - use the modern default format */
>>> 		fmt_cover_letter_commit_list = "log:[%c/%t] %s";
>>> 		break;		
>>> 	default:
>>> 		fmt_cover_letter_commit_list = value;
>>> 		break;
>>> 	}
>>>
>>> Hmm?
>> 
>> Mmh, what if instead we defined a prefix format just like shortlog?
>> Maybe call it something like "numbered" or something similar (not too
>> good with coming up with names).
>> 
>> I dislike the idea of having an option be multiple types. Should bool or
>> string, not both.
>
> I don't mind either way if we can come up with some sensible names 
> instead of "true" and "false".

I do not mind a pair of synonym if you insist, but I disagree with
your assessment on true and false being not sensible.  When you view
the feature as "use the modern commit list format" (specified either
with a command line option, or a configuration variable), "yes, I do
want to use that modern one, not the historical shortlog format" and
"no, don't bother. I like the old one just fine" are both natural
answers to the question "do you want to use the modern one?".  Of
course, "let's use the modern one, and as it lets me give a custom
format string, please use this one" would be how the user feeds a
value that is not boolean to the feature.

So in short, I view this very similar to other "extended bool" (or
"bool or even more customization") option/configuration, and "true"
and "false", while they may not be so descriptive, are also sensible
choices in that context.