Nicholas Clark wrote on 2009-10-19: > On Mon, Oct 19, 2009 at 03:16:38PM +0100, Steve Hay wrote: >> Jan Dubois wrote on 2009-10-14: >>> On Wed, 14 Oct 2009, jesse wrote: > >>> If so, do they need to _not_ have DOS line endings in the repo? It's >>> the 21st century and we all have text editors that know how to deal >>> with line-endings. I'm all for giving them Unix line endings in the >>> repo and the > release >>> and see if anybody complains. :) >> >> Me too. I was going to look at converting any affected Win32 files to >> Unix EOLS, but README.win32 and win32/ all have DOS EOLs in the repo >> anyway. So it's just down to hacking some steps out of the release >> process. > > Not in my *checkout*, they don't I meant in my *checkout* too, believing that that reflected exactly what's in the repo on the basis that I have autocrlf set to 'false' so I thought it didn't do any mucking around at my end. So how come your checkout has DOS EOLs on Win32 files and mine doesn't? > >> There are lots of other files in the repo with DOS EOLs, though. Should >> these be converted to Unix EOLs? >> >> cpan/Compress-Raw-Bzip2/bzip2-src/dlltest.c >> cpan/Module-Load-Conditional/t/to_load/Commented.pm >> cpan/Module-Load-Conditional/t/to_load/LoadIt.pm >> cpan/Module-Load-Conditional/t/to_load/MustBe/Loaded.pm >> cpan/Pod-Simple/t/corpus/2202jp.txt >> cpan/Pod-Simple/t/corpus/2202jpx.txt >> cpan/Pod-Simple/t/corpus/2202jpy.txt >> cpan/Pod-Simple/t/corpus/2202jpz.txt >> cpan/Pod-Simple/t/corpus/cp1256.txt >> cpan/Pod-Simple/t/corpus/fet_cont.txt >> cpan/Pod-Simple/t/corpus/fet_dup.txt >> cpan/Pod-Simple/t/corpus/iso6.txt >> cpan/Pod-Simple/t/corpus/koi8r.txt >> cpan/Pod-Simple/t/corpus/laozi38.txt >> cpan/Pod-Simple/t/corpus/laozi38b.txt >> cpan/Pod-Simple/t/corpus/laozi38p.pod >> cpan/Pod-Simple/t/corpus/lat1fr.txt >> cpan/Pod-Simple/t/corpus/lat1frim.txt >> cpan/Pod-Simple/t/corpus/nonesuch.txt >> cpan/Pod-Simple/t/corpus/pasternak_cp1251.txt >> cpan/Pod-Simple/t/corpus/plain.txt >> cpan/Pod-Simple/t/corpus/plain_explicit.txt >> cpan/Pod-Simple/t/corpus/plain_latin1.txt >> cpan/Pod-Simple/t/corpus/plain_utf8.txt >> cpan/Pod-Simple/t/corpus/polish_utf8.txt >> cpan/Pod-Simple/t/corpus/s2763_sjis.txt >> cpan/Pod-Simple/t/corpus/thai_iso11.txt >> cpan/Pod-Simple/t/corpus2/polish_utf8_bom.txt >> cpan/Pod-Simple/t/corpus2/polish_utf8_bom2.txt >> cpan/Sys-Syslog/win32/PerlLog.mc >> cpan/Sys-Syslog/win32/PerlLog_dll.uu >> cpan/Text-ParseWords/t/ParseWords.t > > That lot, unfortunately, are S.E.P. > So we'd need to send tickets upstream. I'll do that if it's deemed worthwhile. > >> djgpp/configure.bat >> symbian/ext/Moped/Msg/Msg.mmp >> symbian/ext/Moped/Msg/Msg.pkg >> symbian/ext/Moped/Msg/bld.inf > > I don't know about these. The relevant platforms may break. Yes, I wondered about those too. > > > My concern with non-standards in line endings is that whilst most every > editor these days can deal with them, it's only going to take one > "helpful" tool to decide to "convert to native", or to patch a section > of a file to the other sort of ending, and then we'll have either > > a: files in an inconsistent state > b: lots of diffs in commits that are actually just whitespace Agreed, but where does that leave us? Having everything in Unix format would be a simple rule but could cause accidents of the nature you describe on non-Unix systems. But having files that relate to one OS (e.g. the files in the win32/ folder) in their 'standard' format (i.e. the format native to that OS) doesn't help unless users of that OS never touch any files that aren't in their specific area. Having such a mixture of EOLs is surely more confusing and prone to whitespace mishaps than having everything in Unix format (where possible).Thread Previous | Thread Next