Working on Windows, but getting "LF will be replaced by CRLF" when committing in Git

Question

I am checking out from a repository where I am the only Windows user in a sea of Mac and Linux. My IDE is running on my Windows machine, and code is pushed to a VM. The code isn't synced back to the host. When I am ready to add / commit on my Windows host, I get the warning: LF will be replaced by CRLF message.

These are my Git settings :

core.symlinks=false
core.autocrlf=true
core.fscache=true
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
help.format=html
http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
diff.astextplain.textconv=astextplain
rebase.autosquash=true
credential.helper=manager
core.editor='C:/Program Files/Notepad++/notepad++.exe' -multiInst -nosession
core.filemode=false
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true

I'm not sure why core.filemode=false is listed twice.

Is there a reason why I would be getting this warning on Windows? Am I doing something moronic in my settings (totally possible)? Or, does this make sense in this scenario, and if so, why?

Answer 1

Git has two places that line feeds can be controlled:

• In the global config settings on your system
• In the .gitattributes file that applies per repo/project. These settings will override the user's configuration settings.

In your Git settings your have core.autocrlf=true. Meaning you are telling Git to change the line ending to CRLF. You can change this to see if Git stops trying to change the line endings.

git config --global core.autocrlf input

A better approach may be to set the proper line endings in the .gitattributes file. This is committed to the repository in the root and it will overrides user's individual settings. This ensures that all users committing to the repo will have the proper line endings. Because it sounds like you are working on *nix based project it would probably be prudent to set the line endings to line feed. In the .gitattribute files you could have something like this.

# Set all files to have LF line endings
* text eol=lf

This link has a more detailed explanation of the options you can set in the file: https://help.github.com/articles/dealing-with-line-endings/

EDIT 1: Thought I add this from the actual Git documentation: https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration

core.autocrlf

If you’re programming on Windows and working with people who are not (or vice-versa), you’ll probably run into line-ending issues at some point. This is because Windows uses both a carriage-return character and a linefeed character for newlines in its files, whereas Mac and Linux systems use only the linefeed character. This is a subtle but incredibly annoying fact of cross-platform work; many editors on Windows silently replace existing LF-style line endings with CRLF, or insert both line-ending characters when the user hits the enter key.

Git can handle this by auto-converting CRLF line endings into LF when you add a file to the index, and vice versa when it checks out code onto your filesystem. You can turn on this functionality with the core.autocrlf setting. If you’re on a Windows machine, set it to true – this converts LF endings into CRLF when you check out code:

$ git config --global core.autocrlf true

If you’re on a Linux or Mac system that uses LF line endings, then you don’t want Git to automatically convert them when you check out files; however, if a file with CRLF endings accidentally gets introduced, then you may want Git to fix it. You can tell Git to convert CRLF to LF on commit but not the other way around by setting core.autocrlf to input:

$ git config --global core.autocrlf input

This setup should leave you with CRLF endings in Windows checkouts, but LF endings on Mac and Linux systems and in the repository.

If you’re a Windows programmer doing a Windows-only project, then you can turn off this functionality, recording the carriage returns in the repository by setting the config value to false:

$ git config --global core.autocrlf false

Answer 2

There is a common misconception that on Windows, config.autocrlf=true will always make Git use CRLF line endings when checking out files. But if you read the Git documentation carefully, you'll notice:

[Setting config.autocrlf=true] does not force normalization of text files, but does ensure that text files that you introduce to the repository have their line endings normalized to LF when they are added, and that files that are already normalized in the repository stay normalized.

In other words, Git will only use CRLF when checking out files if the files have already been classified as text files when they were committed to the repository. By default, Git does not automatically classify files as text. Yes this is incredibly annoying, but it is a safety precaution so that by default, Git will never corrupt a binary file that it thought was text.

We can prevent this problem by telling Git to determine whether files are text. Either option below works:

1. In the Git attributes file, set the "text" attribute to "auto" for all files. This will configure Git to automatically determine whether a file is text. You can set this either once for each contributor (default location: $HOME/.config/git/attributes), or once for each repo (.gitattributes).

2. If you are on a Windows machine, set "core.autocrlf" to "true". This is the same as #1 but also sets core.eol to crlf, which is why this should only be done for Windows systems.

If you have a repo whose files were not classified as text, you may be getting a bunch of LF will be replaced by CRLF warnings whenever you commit changes to these files. To fix this problem once and for all, after performing the Git configuration mentioned above, run unix2dos on all the files (use find . -exec unix2dos {} \; in Git Bash or an equivalent Windows command), then commit them. The files will be re-classified as text all at once, you'll stop getting the warnings, and you'll also benefit from having CRLF line endings in your working directory. The remote repository will still use LF line endings, but future clones of the repo on Windows systems with the configuration mentioned above will use CRLF line endings locally as expected.