On Sun, May 09, 2010 at 10:45:35AM -0700, Junio C Hamano wrote: > Eyvind Bernhardsen <eyvind.bernhardsen@xxxxxxxxx> 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 -- 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