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

[Robert Buck <buck.robert.j@gmail.com>]

On Mon, May 10, 2010 at 12:33 AM, Eyvind Bernhardsen
<eyvind.bernhardsen@gmail.com> wrote:
> On 9. mai 2010, at 22.46, Robert Buck <buck.robert.j@gmail.com> wrote:
>
>>> 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.
>
>> 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.

Okay, so that makes sense...

   "Files subject to EOL conversion are those that are explicitly
 identified through attributes to be text files, or provided core.crlf is
set to auto, those files 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. When conversions occur the EOL
character changes from the internal LF format to the format specified
by core.crlftype."

This would work out well if file type maps were ever introduced. Type
maps would not short circuit the explicit attributes identified by the
first clause, then for those files without attributes you'd check the
file-type maps, then fall back to the algorithmic if auto is enabled.

I like that.