On Dec 6, 2017, at 2:03 AM, Scott Doctor <sc...@scottdoctor.com> wrote: > > I do not get why that warning even exists.
Because people working on cross-platform projects often have one user (there’s always one) who opens a text file with Unix line endings on a Windows box and commits it with DOS line endings, thus potentially causing downstream damage. You may say, “But all decent tools these days understand both styles!” And you’d be either wrong or at least incomplete while being mostly right. Case in point, if you use autosetup — as the Fossil and SQLite source code bases do, among others — and commit any *.in file with DOS line endings, the next time autosetup processes that file to produce the .in-free output version, you’ll get a mix of DOS and Unix line endings: Unix on those lines where autosetup made a substitution, and DOS on all the other lines. This in turn can break other software. (Ask me how I know.) Another case in point, this time for the opposite case: you might have software that insists on DOS line endings. Let’s pick as a completely random example U/W FOCAL. [1] Even though that software runs under Linux, the input files to U/W FOCAL for that project need to have DOS line endings. And yet another case in point, other Linux software in that same project uses DOS line endings because that’s what the upstream project uses, so if we change them all to Unix style, it complicates merging upstream changes into our source base. So yeah, some of us appreciate Fossil catching unintended line ending conversions for us and would actually like to see an “lf-glob” feature to catch the inverse problem from the one it currently checks for. [1]: https://tangentsoft.com/pidp8i/artifact/15a27bbf29ef6cd9 _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
