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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7 May 2010 17:50, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
>
> On Fri, 7 May 2010, hasen j wrote:
>
>> >
>> > 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.
>
> 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.

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

> If it's _text_, then you import it as such, and set crlf=true so that it
> gets checked out with crlf.

It should be the repository maintainer's responsibility to tell git to
always checkout that file with crlf.

Why?

Because it's part of the project. I never set crlf=true on windows,
but if some files just *have* to have crlf, then I wouldn't mind
having them that way.
This doesn't mean I should have to pollute all my files with crlf just
to please visual studio, or whatever tool requires the crlf endings.

Other developers (specially those new to git) shouldn't have to worry
about crlf issues: when they clone, git would automatically convert
some files to crlf on checkout, regardless of whether or not they set
crlf=true.

git currently has it backward: putting the onus on each individual
contributer to set autocrlf=true

This doesn't make any sense.

If someone did want everything to be crlf, sure, they can set crlf=true.

But there's another potential problem: what if some files just *can't*
have crlf? Say some build (or whatever) tool barfs on crlf files, and
the user sets crlf=true because that's his preferred eol style, but
the project has one of those lf-only files? In this case, we'd want
that file to be always checked out with LF, even if crlf=true is set.
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]