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

On Mon, May 10, 2010 at 12:33 AM, Eyvind Bernhardsen
[off-list ref] wrote:

On 9. mai 2010, at 22.46, Robert Buck [off-list ref] wrote:

quoted

quoted

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.

quoted

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.