> I guess this ultimately comes down to: do we want to force anyone who > checks out the tree on Windows to work with UNIX line endings so that > we don't have to care if our build process handles CRLFs, or do we > want to let people configure their Windows git client to taste (it > will, by default, convert to CRLF, but individual git users can turn > that off) and maybe get potential build issues from it? >
I'm also strongly in favor of forcing LFs on checkout. I've had much more trouble with autoconverted files in the past than with software that can't deal with LFs. The only editor that I've run across that doesn't like LFs is plain old notepad, and also things like VBS files seem to work well with LF line endings. Autoconversion being enabled by default has caused the following problem for me several times: - I usually use Windows for editing as my compilation box is headless. - I tend to use TortoiseSVN from time to time - I sometimes do an SVN update on a network share on the linux box, using TortoiseSVN running on the windows box. - Then I try to compile that checkout on linux, and guess what, all those perl scripts are broken, because TortoiseSVN did convert them to CRLF, which fails on linux for various reasons. So actually I expect more trouble from autoconversion than from forcing LFs even for windows users. Just my two cents... TheSeven
signature.asc
Description: OpenPGP digital signature
