15

Our repository uses LF, my Git for Windows installation uses Checkout as-is, commit Unix-style line endings,

enter image description here

but I still end up with wall of errors in every file I checkout in my IDE as it still receives CRLF all the time even though it does support LF and is configured to use LF via checked in .editorconfig file (or in its own settings).:

.editorconfig 
root = true [*] end_of_line = lf

It is 2020 already and IDEs and tooling already support LF on Windows, so how can I have the nice things too?

Improve this question
1
  • Pls see this answer. With a 4th point added in your case : core.eol=lf. Try with a fresh repo before trying to clean messed repos. Important to emphasize: autocrlf should be false at all levels: system, global, repo Commented Jul 27, 2020 at 7:01

2 Answers 2

Reset to default
26

There are two git config attributes that affect the line endings: core.autocrlf and core.eol.
Previously, you were told to use core.autocrlf = true to be able to work on cross-platform projects, but it's not true any more.

If your system/IDE/tooling support LF and you do want to use LF as everyone else in your team without any silent lf->crlf->lf normalizations, you must turn off autocrlf and configure eol to not infer native line endings, but force it to use lf.

Now there are two ways to achieve LF in all your files a/o repos:

  1. Globally for all repositories on your local machine.
  2. Per-repository via checked-in .gitattributes file.
    This file overrides any local configuration for everyone who clones the repo.

I personally recommend to go with both for all local repos and to ensure cross-platform cross-dev consistency.

1) Globally for all repositories on your local machine

Being in your working directory (your local repo):

  1. First commit everything

  2. Let's be paranoid a bit and set it both globally and in repo as well. Just in case.

    git config --global core.eol lf git config --global core.autocrlf false git config core.eol lf git config core.autocrlf false

  3. Delete everything "code" except .git.
    You can also omit dependencies, installed files (such as node_modules), build files and any git-ignored file as well.

  4. and lastly run

    git reset --hard HEAD

Things should be working now. Newly checked files should follow the new configuration and keep whatever line-endings were cloned from the remote repo.

Note that if your remote repo uses mix of crlf lf endings, you will also have to run and push

git add --renormalize .

2) Per-repository via checked-in .gitattributes file

Being in your working directory (your local repo):

  1. Create .gitattributes file in the root with this content:

    * text=auto eol=lf

  2. Commit the file (and everything else)

  3. Same as above

  4. Same as above

IMPORTANT NOTE: After you introduce the file into the repository, it is necessary that everyone who still has old CRLF files does step 3 and 4 to update their working directory as just checking out the commit doesn't affect already existing files.

git reset hard

Notes

setting core.autocrlf to true or input overrides core.eol

https://www.git-scm.com/docs/git-config#Documentation/git-config.txt-coreautocrlf

core.autocrlf = input is the preferred value on unix systems. https://stackoverflow.com/a/41282375/985454
https://stackoverflow.com/a/4425433/985454

Troubleshooting

Reinstall git for windows with third option (as in the screenshot in Q)

Checkout as is - Commit as is (core.autocrlf = false)

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

For step 3 you could use something like git ls-files -z | xargs -0 rm to only remove git tracked files.
@Qtax I have no experience with this command in particular, but if it does what you say then definitely.
4

The way to go is to use a .gitattributes with the good instruction to give to git.

See https://www.edwardthomson.com/blog/git_for_windows_line_endings.html

For your case, it should be: * text=auto eol=lf

.editorconfig is only for saving files for editors supporting it...

But after that, you will have to normalize the files:

git add --renormalize .

You could find this answer useful: https://stackoverflow.com/a/50645024/717372

Improve this answer

11 Comments

Actually I don't want CRLF. And yes, I am talking about IDE and tooling that supports LF, hence the .editorconfig. From what I have learned, .gitattributes can be quite complicated and you need to tweak certain extensions there. Anyway, to use .gitattributes you still need to make sure each dev's git installation is set properly and therefore I think the other solution is more straight forward and requires less work and further maintanance.
I mean, .gitattributes file works only if you also set core.autocrlf = false. But if you also set core.eol = lf, then the .gitattributes has implicitly value * text=auto eol=lf even if you don't create it IIUC.
No, .gitattributes overrides core.autocrlf, period. Get it right, check it in to your repository, and it doesn't matter what core.autocrlf or core.eol are set to. That's the point of .gitattributes.
No. .gitattributes overrides core.autocrlf, it doesn't matter what you have it set to. If you have a .gitattributes configured for a file, core.autocrlf will be ignored.
That makes sense - you were (hopefully) already normalized since core.autocrlf indicates that files are CRLF in the working directory but go into the repository as LF. In your new setup, you want files as LF in the working directory and the repository. So there's nothing to renormalize in your repository. Indeed a fresh checkout is all that's needed to update the on-disk files.
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.