On 9. mai 2010, at 13.14, Robert Buck wrote: > 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? No, "auto" means to enable normalization for files git doesn't identify as text files, "true" means to always normalize, and "false" means never normalize. I probably wouldn't implement "input" unless there was a lot of demand. The idea is to make it act exactly like the "crlf" attribute, even though "core.crlf=true/false" would probably be used very rarely... I'm having second thoughts, actually. > core.localcrlf [ crlf | lf ] : this is obvious, and use-friendly Well, yes. I was thinking "true|false" (ie "I want crlf" or "I don't want crlf"), but I'm having second thoughts about that, too. > For the above case have you considered using 'core.crlflocal' instead? > Usability-wise the related properties start with the same name prefix. I didn't think too much about the name, so a completely different name might be even better. Because of this and my second thoughts, I'm going to wait a few days before I make any more changes to allow good ideas to appear and give them time to sink in. > 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 Agreed, but I think getting this feature included is more important than getting the user interface exactly right. A compromise between backwards compatibility and user friendliness is okay. > 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. Yes, my "localcrlf" would be true/false instead of crlf/lf. It's definitely a compromise :) -- Eyvind -- 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