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

> Some sort of DWIM (e.g., it is not "shortlog", so it must be "log:"
> as there is nothing else supported) can be beneficial to help make
> it less cumbersome for users to type for command line options, just
> like we did for "git log --pretty=X" where we take a string with '%'
> in it as a cue to default to "--pretty=tformat:".  But as "set and
> forget" facility, there is no strong need to prefer "%s (%an)" over
> "log:%s (%an)" on the configuration variable side (other than being
> consistent to the command line option parsing).  We would probably
> want to give an escape hatch in the design to avoid painting
> ourselves into a corner we cannot get out of (imagine what happens
> when later others want to use something completely different from
> the log-pretty machinery, making "not a shortlog, must be log:"
> assumption invalid).
> 
> Something like
> 
>   "log:" is prefixed to the string value, UNLESS the value matches
>   "^[-a-z0-9]*$" or the value matches "^[-a-z0-9]*:".
> 
> would probably be extensible enough.  To avoid exposing regexp to
> the users, we can say "a string that is not an alphanumeric token,
> nor an alphanumeric token followed by a colon, is prefixed with
> 'log:'", or something.
> 
> WIth such rules in place, a new fixed format other than "shortlog"
> can be introduced (e.g., "middlelog") without getting munged into
> nonsense "log:middlelog", and a new parameterized format other than
> "log:" can be introduced (e.g., "pretty:%(subject) %(author)")
> without turning into a nonsense "log:pretty:%(subject) %(author)".
> 
> Or we do not have to worry about these if we just use what the user
> gives us without any DWIM.  I just do not think we want to see the
> "not a shortlog?  must be log" burned into the syntax that will have
> to stay with us forever.