1

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:

enter image description here

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?

Lajos Arpad
  • 45,912
  • 26
  • 82
  • 148
  • Workaround solution - Give a try with : `git commit -m --no-verify`. This will bypass the hooks configured for your linter. – Dev-vruper Mar 02 '21 at 17:12
  • @Dev-vruper I would be extremely happy not to have use this. But the client seems to give it importance. However, figured out some solution which worked: `git config --global core.autocrlf input` and then modify foo.js and then `git add --renormalize foo.js`. But working like this is very unfomfortable. If I knew that some automatic code would block me because of white characters, I would have not chosen to be a programmer back in the day. Nowadays the greatest difficulty is to comply to the ever increasing technical beaurocracy. – Lajos Arpad Mar 02 '21 at 17:26
  • If a youngster asks me whether it's a good idea to become a programmer, my answer will be NO. – Lajos Arpad Mar 02 '21 at 17:28
  • Lajos, I have to find the answer still, but I remember that `rm .git/index && git reset` should help after properly configuring the eol settings. (BACKUPS are a good idea here). Let me find the answer so I can link it – knittl Mar 02 '21 at 19:47
  • What is your `core.autocrlf` setting? – knittl Mar 02 '21 at 19:55
  • @knittl it was set to input since I have asked the question. I do not know what its value was before I changed it. – Lajos Arpad Mar 03 '21 at 09:15

1 Answers1

2

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.

torek
  • 330,127
  • 43
  • 437
  • 552
  • Thanks, this answers the question. Basically I solved it yesterday via core.autocrlf, due to the urgency, but it makes perfect sense to use default settings wherever possible and for those repos where some other settings are needed, the specificity of those particular repos can be handled via .gitattributes in the project folder. I did not try this out yet, as the issue is already solved, but will definitely work this way the next time I have similar issues. It's much better to avoid global settings when the issue is with a specific repo. – Lajos Arpad Mar 03 '21 at 09:20