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

Phillip Wood [off-list ref] writes:

quoted

quoted

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.