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

[Finn Arne Gangstad <finnag@pvv.org>]

On Sun, May 09, 2010 at 10:45:35AM -0700, Junio C Hamano wrote:
> Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com> writes:
> 
> > My user interface would have been:
> >
> > - an attribute "eolconv" that enables or disables line ending conversion
> > - a config variable "core.eolconv" that sets "eolconv" for all files where it is unset
> > - a config variable "core.localeol" that decides whether LF or CRLF is preferred
> 
> I am puzzled about this second item; what is its type and what is its
> purpose?  If it is to allow project-wide default to be specified, then
> isn't having "* eolconv=true" in .gitattributes a much better option and
> is already supported by the first item?

The way I understood it core.eolconv has exactly the same possible
values as the "eolconv" attribute, and serves as a default value for
"eolconv" if it isn't set. This would (mostly, I guess) be for Windows
users who would like to check out a project that is primarily
developed on Unix and didn't bother to set any eolconv attributes, and
still get CRLF line endings. core.eolconv has some of the drawbacks
of autocrlf, so shouldn't really be used if you can convince projects
to add eolconv attributes instead.

Are you thinking we could live completely without it? Most other
popular vcs-systems have eol-conversion/normalisation on by default,
while git has it disabled by default. The config variable can change
the default behaviour, but is isn't as helpful as it should have been
perhaps.

To do a better job with old un-normalised repos, we could for each
file remember what their eol-style was (CR, LF, CRLF, mixed), and then
even if doing output conversion on checkout, convert back to the same
eol style on commit. This would perhaps break down a bit for renames,
but would be lovely if it worked for merges for example...

- Finn Arne