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

On 7 May 2010 18:33, Linus Torvalds [off-list ref] wrote:

On Fri, 7 May 2010, hasen j wrote:

quoted

On 7 May 2010 17:50, Linus Torvalds [off-list ref] wrote:

quoted

quoted

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.

Umm. Then it's not text, is it? What you are describing is a binary file
that happens to look like text with CRLF.

That depends on your definition of text.

Well, my definition of text is "does it make sense to do any end-of-line
conversions". That's the only definition that makes sense for an SCM, at
least in the current context. If doing conversions on the line endings is
wrong, then it's not text.

And your whole premise was that conversions were always wrong. So the way
you put it, that's not a text-file, it's a binary file.

quoted

Storing it with LF internally is ok, as long as we can have it
*always* be checked out as crlf.

.. and that's what I suggested "core.crlf=on" would mean.

However, if you think that it needs to be CRLF on _all_ platforms, even
platforms where CRLF is _wrong_ for a text-file, then see above: in that
case it's not a text-file at all as far as the SCM is concerned.

In that case it's just a binary file, and CRLF is _not_ "end of text
line", it's part of the definition of the format for that binary file.

                       Linus

(sorry about the previous message, forgot to make it reply all)

What does the platform care? This doesn't make any sense. Files that
need CRLF are not Unix files to begin with (e.g. sln).

My whole argument is based on a simple premise: LF -> CRLF doesn't
make sense because all windows editors can handle LF endings, and
because it just causes a lot of confusion.

Until Erik brought up the case where a multi-platform project uses
different build systems on each platform.

I don't know if .sln is one of these formats where the tools will
vomit if it's not crlf, but let's just assume so.

- *.sln is not a Unix file, so it's perfectly ok (maybe even
desirable) to check it out with crlf.
- it's an exception; git doesn't have to convert _all_ files to crlf;
just the .sln ones.