The case against "eol = clean"

[Ian Clatworthy]

Robert Collins wrote:
> On Sat, 2009-03-28 at 13:04 +1000, Ian Clatworthy wrote:
>> Robert Collins wrote:
>>> On Sat, 2009-03-28 at 09:53 +1000, Ian Clatworthy wrote:
>>>> I'm also considering adding a value called "clean". That would work
>>>> exactly like "exact" except it would warn if mixed line-endings
>>>> were found in a file. What do you think? Git has something like this
>>>> so I gather it's of value to users.
>>>
>>> -Rob
>> I assume you meant to say something other than you name here? :-)
> 
> Yeah, I meant to have a +1 there. Dunno where it went :(.

Exploring this more, I'm against "eol = clean" at the moment.
It turns out the driver behind git's feature was detection of
potential corruption in "binary" files that git thinks are text
files. So that detection needs to happen *across* "eol = windows"
and "eol = dos" matches - it's of limited/no value when the
content is being checked in unchanged (as eol = exact does).

Wondering out loud, maybe a separate "whitespace" filter is
the better place for this? That filter could do stuff like:

* warn about mixed line endings being detected
* warn about trailing whitespace on end of lines
* warn about a missing newline at end of file
* strip trailing whitespace at end of lines
* replace tabs with spaces or vice versa
* etc.

Imagine something like ...

[name *]
whitespace = warn-mixed-newlines,trim-trailing-whitespace,expand-tabs

Ian C.