Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization

Part of the confusion comes from the way the options are currently
declared.  set vs. unset vs. unspecified vs. "input" vs. "auto" for an
option named "crlf" is just very, very, unfriendly.  None of the words
*mean* anything.

Maybe we should rethink this from the top.  Imagine that we currently
have no crlf options whatsoever.  What *should* it look like?  I
suggest the following:

Config:
  core.eolOverride = lf / crlf / auto / binary / input
  core.eolDefault = lf / crlf / auto / binary / input

Attribute:
  eol = lf / crlf / auto / binary / input

If eolOverride is not "auto" or unspecified, we ignore eolDefault or
any attributes.

If the attribute is not "auto" or unspecified, we ignore eolDefault.

For all entries, unspecified is equivalent to "auto".

Of course the eol attribute could be named "crlf", but that might not
increase the sanity as much as we would like.

And "input" means "auto, but strip CR when committing."  Or maybe the
problem is that it doesn't belong here at all: maybe it should be an
entirely separate attribute that takes effect whenever the eol
attribute/config resolves to "auto."

Or maybe I'm just not thinking about it the right way?

Avery

If we forget everything git has now, I would suggest the following:

- eol-normalization is per repository, per filetype (fnmatch filter)
- in a file separate from .git/config, such as .git/eol
- when you clone, you get this file

You specifies the 'standard' eol type for each file type in this project:

    *.c lf
    *.python lf
    *.vb crlf
    *.sln crlf
    etc (something like that)

committing and checking-out always normalize line endings; *always*

add (and commit) can take an option to keep eol as-is (i.e.
--no-eol-normalization or --keep-eol or --raw-eol)

In this model:

1- Anyone who clones gets the repository eol settings
2- No one can possibly commit in a different eol style unless he
explicitly says he wants to.
3- Naturally, eol-normalization doesn't apply to binary files

#2 is important, it's needed so you won't have someone making bad
commits because he has a settings some where in his global config to
always ignore eol normalization.
on the other hand, one can alias 'add --raw-eol' to something like
'eviladd', so he can do 'git eviladd file.c', which is fine because
it's explicit.

This would get rid of issues where an editor (such as VS) saves a file
with mixed line endings: we don't care because we normalize them.

This would also make it more transparent to windows users: they don't
even have to think about eol issues; they can't make bad commits
"by-accident". (provided the repo maintainer has set the eol filters
properly).

I have no idea what happens (or should happen) if the origin repo
maintainer updates the .git/eol file. Maybe it should be .giteol
instead of .git/eol