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

From: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Date: May 10, 2010, 04:33 UTC
Message-ID: <91F47297-A1B5-4AE5-8835-E3A8E452FB8A@gmail.com>
In-Reply-To: <AANLkTikg7Tc6zJvfBELBQoeAxebFenNLivEs92j8c83D@mail.gmail.com>

On 9. mai 2010, at 22.46, Robert Buck <buck.robert.j@gmail.com> wrote:

Show 10 quoted lines

>> 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 missed something. The part that confuses me in this
> statement is that you said "for files git doesn't identify as text
> files". The convert.c source is the heart of this, and if a file is
> not identified as text it is presumed to be binary. The statement made
> seems to imply you'd auto-convert PDF files? I know you did not mean
> that, but it could have been read that way.

Doh! I meant to write "files git _does_ identify as text files". Sorry for the confusion.

Show 8 quoted lines

> What specifically happens in the three modes? Would it be precise to
> say the following?
>
>    "Files subject to EOL conversion are those that are explicitly
> identified through attributes to be text files, or those
> algorithmically determined to be text files which happen to not bear
> the "text" file attribute. Otherwise the default value, "false",
> applies and no EOL conversions occur."

Very close, but my thinko threw you off. The "algorithmic determination" of text files is only performed when crlf=auto, either by the attribute or the config variable being set that way.

The point of the "core.crlf" config variable would be to provide a default value for the "crlf" attribute.

-- 
>
Eyvind