This is imo ultimately a problem with git.

If git didn't have this setting, then after checking out a bash file with LFs in it, there are many Windows editors that would not be able to edit that file properly. That's a limitation of those editors & nobody should be using those pieces of software to edit bash files. This is a problem that is entirely out of scope for a VCS & not something Git should ever have tried to solve.

In fact, having git solve this disincentives Windows editors from solving it correctly.

> I don't see how this is whole situation is the problem of any Linux tooling

Well, bash could also handle crlf nicely. There's no gain from interpreting cr as a non-space character.

(The same is valid for every language out there and all the spacey things, like zero-width space, non-breaking space, and vertical tabs.)

You will have the same problem if you build a Linux container image using scripts that were checked out on the windows host machine. What's even more devious is that some editors (at least VS Code) will automatically save .sh files with LF line endings on Windows, so the problem doesn't appear for the original author, only someone who clones the repo later. I spent probably half a day troubleshooting this a while back. IMO it's not the fault of any one tool, it's just a thing that most people will never think about until it bites them.

TL;DR - if your repo will contain bash scripts, use .gitattributes to make sure they have LF line endings.

The biggest mistake was running Linux programs over files created by Windows programs. Anything you move between those worlds is suspect.