How to work if Linter throws error at every line?

Trying to work on a project, but I cannot commit because some Linter is under use. It throws errors like:

Expected linebreaks to be 'LF' but found 'CRLF'

I tried to follow the instructions at How do I force git to use LF instead of CR+LF under windows?

git config --global core.eol lf

and even

git rm --cached -rf .
git diff --cached --name-only -z | xargs -n 50 -0 git add -f

I'm prevented from having any progress by Linter:

I would like to somehow comply to the rule with the LF and CRLF, but my tries failed. I'm trying this in the last 30 minutes, searching on search engines and trying to find it out. How can I solve this problem?

I recommend not using core.autocrlf at all. Instead, create a .gitattributes file. In that file, use eol=lf as a setting for any file that should be stored in the repository with LF-only endings; use eol=crlf as a setting for any file that should be stored in the repository with CRLF settings. See also VonC's accepted answer to the linked question.

Meanwhile, files in your working tree will have whatever setting your host OS wants. To understand what this means, remember that in Git, committed files—files actually stored in Git—are read-only, compressed, de-duplicated, and generally completely unusable. None of the rest of the software on your computer can read or use them. Therefore, they must be copied out of Git to turn them into ordinary (and usable) files.

This means that the files that you see and work with are not in Git at all. They were just extracted from Git earlier, to fill your working tree. Those ordinary, usable files can have whatever line endings your system wants. When Git prepares files for a new commit, Git can strip the original line endings and put in LF-only line endings.

Any pre-commit hooks that try to figure out whether what you're committing, is OK to be committed, had better be looking, not at the files you have in your working tree, but at the files that Git will look at, to put in the next commit. Those files will have whatever line endings you told Git to put in them, courtesy of the .gitattributes file, where you get to control each file individually, rather than the One Big Hammer method with core.autocrlf.

In the end, both should work. You do need Git 2.16 or later to get git add --renormalize . (which you really want to have; the other methods of doing that are ugly at best). The method knittl mentioned in a comment, of using rm .git/index && git reset, does also work as long as you are in the main work-tree; that's the method that is just mildly ugly.