Re: [PATCH/RFC v2 1/4] Add "core.eolStyle" variable to control end-of-line conversion

[Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>]

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