[PATCH v3 0/5] End-of-line normalization, redesigned

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