After Finn Arne's bombshell of a patch, I was almost ready to throw in the towel on this series. Then I realized that just because autocrlf is safe to use now doesn't mean it solves my CRLF-related problems. The reason is that since autocrlf doesn't require your text files to be normalized any more, it also doesn't guarantee that they are. If you need to interoperate with some other SCM, have tools that require a specific line ending, or you just like your repository free of CR characters, autocrlf doesn't do that. This series does that. There have been some changes since v2: - Series is now based on Finn Arne's "safe autocrlf" patch (I took the one from "pu" since Junio seems to have fixed some whitespace damage). - Removed core.eolStyle. This gets more explanation below. - Added "crlf=lf" and "crlf=crlf"; they turn on normalization and convert line endings to LF or CRLF on checkout, respectively. Yes, I know. - RFC patch: As promised, rename "crlf" attribute as "eolconv", keeping "crlf" as an alias for backwards compatibility. I think this one might be worth it, but perhaps not as implemented (see the fix I made for git-cvsserver.perl to understand why). - RFC patch: Rename "core.autocrlf" as "core.eolconv". This one is mainly for fun, not so much for inclusion: it might have the same problems as adding an alias for "crlf" and I'm not too bothered about the name any more anyway, as I'll explain below. So if I've removed eolStyle, how does the user say what line endings to use for a normalized text file in the working directory? Using "core.autocrlf". There are three reasons why that isn't completely insane: 1. A user who wants CRLFs in text files probably doesn't want them just in files that happen to have normalized line endings. 2. You can force CRLF in the working directory now, so if you just want .vcproj files and the like to have CRLFs, you check in a .gitattributes containing "*.vcproj crlf=crlf" or add that line to your .git/info/attributes. No need to use autocrlf at all. 3. With the "safe autocrlf" patch, core.autocrlf is actually safe to use in a non-normalized repository, so "core.autocrlf=true" is no longer an insane default. Given the intended usage for autocrlf it's not even a particularly bad name any more: "I don't care how you do it, I just want CRLFs in my text files". Even "autocrlf=input" isn't that bad if you squint a bit. After a few beers. Summary: the new "core.autocrlf" is for when you don't want to mess up an existing repository with unwanted CRLFs, and the new "crlf" mechanisms are for normalizing text files. Eyvind Bernhardsen (4): Add tests for per-repository eol normalization Add per-repository eol normalization Rename "crlf" attribute as "eolconv" Rename "core.autocrlf" config variable as "core.eolconv" Finn Arne Gangstad (1): autocrlf: Make it work also for un-normalized repositories Documentation/config.txt | 26 ++++--- Documentation/gitattributes.txt | 157 ++++++++++++++++++++++++++++++--------- attr.c | 2 +- cache.h | 9 ++- config.c | 13 ++- convert.c | 115 +++++++++++++++++++++++----- environment.c | 2 +- git-cvsserver.perl | 8 ++- t/t0020-crlf.sh | 106 ++++++++++++++++++++++++++ t/t0025-crlf-auto.sh | 134 +++++++++++++++++++++++++++++++++ 10 files changed, 497 insertions(+), 75 deletions(-) create mode 100755 t/t0025-crlf-auto.sh -- 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