On 7 May 2010 17:50, Linus Torvalds <torvalds@linux-foundation.org> wrote:
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.
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html