> Part of the confusion comes from the way the options are currently
quoted text
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html