Remove all ^M (carriage return) from source files
hostilefork opened this issue · 7 comments
Windows and Linux/OSX differ on the convention of whether newlines are signified by CR or CR LF.
There are some files checked in at the moment which have ^M in them, because someone (me) didn't check over it before committing them.
So we should remedy this. I am not rewriting the history again, so we'll have to do this in the "conventional" way...
@sorenhein one reason this didn't make it into v2.8.0 is because I noted that the dll.h and portab.h files were among the ones with these line endings. Given you wanting to go ahead and get the source out, thought I'd shelve the debate. But traditionally @bohag has distributed these to Windows users with a DLL...so the question comes up as to which standard to cater to.
http://blog.codinghorror.com/the-great-newline-schism/
While most developers are used to working with files that don't have the Windows line endings (all source editors, incl. Visual Studio, I know work with either)... I guess the question is if there is a distributional need to have these line endings in those headers for the ZIP.
I personally feel that normalizing everything to \n is the best idea, and to tell people who develop on Windows to use tools that can cope. It's a rare tool in this day and age that can't cope either way, but a standard helps especially in collaboration vs. a mixture.
Some data on whether anyone has ever brought it up or mentioned it might be helpful.
There was a bug in pre-release 2.8.0 where a #define was split in two lines causing GCC to error on the orphaned second line.
#define AB_COUNT(a, b, c) ^M
thrp->ABstats.IncrPos(a, b, c)
in ABstats.h (an effected file)
T avoid mistake like those please turn to \n linendings exclusively.
Yeah, I don't know where it comes from. I develop on Cygwin using vim as the editor. I thought the astyle+script pass fixed this as well, but I guess not. I'm going to try this next:
http://unix.stackexchange.com/questions/44616/why-is-vim-creating-files-with-dos-line-endings
I think it's a multi-tool issue including git as well. I've fixed some files manually and changed a git setting. Let's see if it helps.
Actually, once I get core.autocrlf to true, SourceTree no longer considered my conversions to be check-in worthy at all. Maybe you users can also make sure that core.autocrlf is set correctly for you?
I've fought with this question in the past, and I thought they'd defaulted it to true, but apparently no. Conventional wisdom is apparently:
Unless you can see specific treatment which must deal with native eol, you are better off leaving autocrlf to false.
Somehow this crops up once in a while, but it seems clean for now.