> My user interface would have been: > > - an attribute "eolconv" that enables or disables line ending conversion > - a config variable "core.eolconv" that sets "eolconv" for all files where it is unset > - a config variable "core.localeol" that decides whether LF or CRLF is preferred > [...] > My current thinking on how to change my series now runs along these lines: > > - keep the current "crlf=auto" change > - rename "core.eolStyle" to "core.localcrlf" > - add a "core.crlf" that sets the "crlf" attribute on paths where it isn't explicitly configured > - keep "core.autocrlf" for backwards compatibility, but make "core.autocrlf=input" and "core.autocrlf=true" complain if they are in conflict with the other config settings. So, the meanings of these would become... core.crlf [ auto | input | false ] : 'auto' means to enable bidirectional normalization, and 'false' would mean do not normalization, and 'input' would mean normalize on input only, otherwise output lf. Is this true? core.localcrlf [ crlf | lf ] : this is obvious, and use-friendly For the above case have you considered using 'core.crlflocal' instead? Usability-wise the related properties start with the same name prefix. >From a usability standpoint, I personally prefer something similar to what you (see "my user interface would have been") specified, slight adjustment to the names only: core.eolconv [ true | false ] - whether or not to turn on conversions core.eoltype [ lf | crlf ] - by default what to convert to for text files I like this purely because, from the users standpoint, saying something like "localcrlf crlf" is strange; meaning the term "crlf" is on both sides of the assignment. I do prefer "eol... crlf", where eol refers to the applicability of the property and crlf is only one such value. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html