Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization

From: hasen j <hasan.aljudy@gmail.com>
Date: May 7, 2010, 23:47 UTC
Message-ID: <q2y600158c31005071647i80871db0z7a55ae77e738d0d4@mail.gmail.com>
In-Reply-To: <alpine.LFD.2.00.1005071601470.901@i5.linux-foundation.org>

Show 5 quoted lines

>
> The only reason to ever support 'lf' is
> if you're a total moron of a SCM, and you save files you know are text in
> CRLF format internally. That's just f*cking stupid.
>

What if:

- The entire history of the file is stored in CRLF
- It's a windows-only file where the official "tool" that reads it
barfs on LF line endings.
- Third party tools also expect (or at least, handle) CRLF line endings.

Even if you end up deciding to store it with LF line endings internally, it should still be *always* checked out with CRLF endings.

And no, just because I want certain files to be checked out with CRLF endings, doesn't mean that I want all files to be checked out that way. This is one of the areas where git's crlf handling is lacking right now.

Also, git-diff should ignore eol differences by default, unless explicitly asked not to (currently it's the other way around).