Thread (32 messages) flat view 32 messages, 7 authors, 2016-06-15

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

From: Eyvind Bernhardsen <hidden>
Date: 2016-06-15 22:48:46

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help