> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html