Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization
- From
hasen j <hasan.aljudy@gmail.com>
- Date
- May 7, 2010, 22:54 UTC
- Message-ID
- <x2i600158c31005071554pdc399a46s1f97b1ddcd258d3e@mail.gmail.com>
- In-Reply-To
- <h2q32541b131005071534r22cc2092t2a21bfad6d4bfd81@mail.gmail.com>
Show 35 quoted lines
> 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