Apparently, our customers are the users who need carriage returns. Instead of telling them to fix their configs and remove CRs from their source code, we decided to make things Just Work™.
On Windows, it's not hard to get CRs in your source. With the default git config, cloning a repo gives you text files with CRLFs. Other source control systems do this as well. Many editors on Windows default to CRLF, but even those that auto-detect line endings won't help if your source control munges the lines.
Yeah, git's default config also corrupts files by playing with line endings. Meaning the hash of a file on my Windows disk is different than on Linux. Meaning my strings are now shorter/longer. It confuses me just as much in git.
I wonder what editors they're using on Windows that it matters. But good that you're listening to customers.
On Windows, it's not hard to get CRs in your source. With the default git config, cloning a repo gives you text files with CRLFs. Other source control systems do this as well. Many editors on Windows default to CRLF, but even those that auto-detect line endings won't help if your source control munges the lines.