I think the issue is that people don't make their own lives harder, but sometimes they make the lives of other people harder (often unintentionally). In my experience, the CRLF files I run into tend to come from developers who are only working in Windows and either aren't aware of the issue or don't particularly care to do anything about it. It isn't something I run into often when cloning a git repo, but having recently started dabbling in the world of mod development for games, there's a lot of stuff out there that seemingly has never been touched by someone who's used Linux before. To be clear, I don't blame anyone for this, since people working on things for free in their spare time shouldn't have to worry about anything other than what interests them, but it's a bit amusing to me that I sometimes have less to configure to run an .exe on Linux than I do to start editing the source for it in a way that makes it easy for me to merge any new changes that happen upstream.

> I sometimes have less to configure to run an .exe on Linux than I do to start editing the source for it in a way that makes it easy for me to merge any new changes that happen upstream.

Are you doing anything more than calling dos2unix?

The language runtime will insert/remove CR for you if you open the file in text mode on Windows. You'd be surprised how much stuff cygwin itself actually does for you. If your code isn't too Linux specific try building it under mingw instead and you can see what's actually going on.

Cygwin does NOTHING under the hood, because I asked it to do nothing. I am aware of text mode of open() under Windows/Mingw. Im also aware of possibility to do CRLF <-> LF translation under cygwin. I never liked it, and I went to LF only quickly. Hence, I use it everywhere and live is easier :)

> Who in his sane mind uses CRLF even under windows? All my source codes are in UNIX format (aka LF only) and I use it consistent under Windows, Cygwin and UNIX.. Why make your life harder?

Why would you use LF if the focus of the application that you develop is Windows? You make the life harder for these users. :-)

Seriously: your argument typically comes from developers who consider GNU/Linux as a first-class citizen as a development or deployment platform, and Windows only as a second-class citizen (assuming that a Windows port actually exists).

I can accept an argument like "I, as a developer, don't care about Windows and its users, so all my source code is in UNIX format." This is a conscious, though quite political decision.

But an argument like "not using LF makes lifes harder" without a relativization on which premises this claim is build (such as "GNU/Linux and macOS users are much more important for as, and if there exist any users or developers who use Windows, we consider them to be undesired, because they make everybody's lifes harder") is intellectual ignorance.

Using LF on Windows is really not difficult. Any text editor actually worth using supports both types of line endings - even Notepad has handled this correctly for years now, from what I remember. I've never been caused any inconvenience as a Windows user by files with LF endings. I never use CRLF if I can avoid it; I only will if working on a codebase that already uses it throughout.

Oh, its simple. There are many many flavors of UNIX and only one Windows. Hence, I see LF as more portable way to store source code, thats why it is prefered. Additionally, im heavy CLI user so again, more geared toward UNIX systems.

If you develop on windows and only for windows, use CRLF all the way. Just do NOT forget to set .gitattributed correctly, and you are set.

> There are many many flavors of UNIX and only one Windows.

With ReactOS, there even exists a flavor that is not developed by Microsoft. If you consider Wine and its derivates as an implementation of the WinAPI, you have one additional (or multiple if you consider their derivates) implementation of the WinAPI.

Even if you only consider the flavours of Microsoft Windows that are full operating systems, you immediately get multiple ones:

- the discontinued Win 9x series

- the discontinued Windows CE, Windows Embedded CE, Windows Embedded Compact, Windows Mobile, Windows Pocket series (technically quite different from both Windows 9x and Windows NT)

- Lots of variants (indirectly) derived from Windows NT:

* Windows (desktop OS)

* Windows Server

* Windows IoT (I would claim that at least for the Windows 10 IoT Core version, the user experience is quite different from both desktop and server Windows)

* Windows PE [1]

* Further discontinued variants such as Windows Phone

[1] https://en.wikipedia.org/wiki/Windows_Preinstallation_Enviro...

The only valid reason you mention here are legacy Windows, like 9x series. Anything NT based is happy with LF only if you have right tools.

I never touched ReactOS, but I suspect is modern enough to handle LF only too. It was targeting Win2003 AFAIR.

So yeah, I stand corrected abit. If you develop only for windows (especially legacy), use CRLF. Anything w/ portability in mind, go for LF only...

The ability to do that is a recent development. And numerous programming environments still default to adding CRLF and stripping it off when running on Windows, and all the system tools on Windows generate files with CRLF as line terminators so all software needs to deal with them.

> Who in his sane mind uses CRLF even under windows?

Hopefully nobody is using it for documents, but most text-based internet protocols, including SMTP and HTTP, use CRLF for line endings.

I fully agree, but we're talking history here, before Unix existed.

The confusion about "LF" (Unix) vs "CR" (Apple) vs "CR/LF" (MS/DOS & Windows) is because we didn't have an explicit "Line End" character in 7-bit ASCII.

There was "EOT" (Ctrl-D/ASCII 4/EOF in Unix) , "ETX" (Ctrl-C/ASCII 3), and other characters that were used to mean other I/O, including ones that didn't match the ASCII definition like Ctrl-S/Ctrl-Q to stop/start I/O, and Ctrl-Z to mean EOF (MS/DOS & Windows).