Updating the Git index failed, LF will be replaced by CRLF?

Question

I\'m using git-gui for version control and pushing them to remote locations. When I tried to Rescan files for changes, I got this message and I\'m not sure what that means. Plea

Answer 1

The solution is to accept that behaviour. You're on Windows so you should have autocrlf as true. It's there so line-endings in Git's internal records are consistent. The warnings are there so you can see if you're about to accidentally corrupt binary files during a commit.

Click Continue. If you want to prevent it happening on those files again, you need to unstage those files, then correct the line-endings and stage them again. Do so by changing the line-endings of the file to CRLF/Windows in your editor, or drop these command line tools into your system32 directory so you can do unix2dos some_file.java on such files at any command prompt.

Answer 2

I faced similar issues and decided to have a closer look to my configuration.

New Line Characters on Windows / Linux / MAC:

1. MAC OS before X: \r = CR (Carriage Return)
2. MAC OS X / UNIX: \n = LF (Line Feed)
3. Windows: \r\n = CR + LF

Don't panic. Git can handle the conversion between platforms for you.

Git should store the line ending as LF in the repo.

Set it to;

TRUE - If you are on Windows:

git config --global core.autocrlf true

This converts LF endings into CRLF when you check out code.

INPUT - If you are on a MAC/LINUX:

You don't need to convert anything, Git uses LF and your MAC uses LF.

But, you can tell git to convert any CRLF if one pass through:

git config --global core.autocrlf input

False - Not recommened

I don't recommend this, but just for the sake of this explanation:

If you are a windows dev only working on windows machine and you are 100% sure you will never work with people on MAC:

git config --global core.autocrlf false

UPDATE:

As commented below, I didn't mention the .gitattributes where one can default these settings for a project.

If you havetime, here is the doc: http://git-scm.com/docs/gitattributes

Answer 3

In Unix systems the end of a line is represented with a line feed (LF). In windows a line is represented with a carriage return (CR) and a line feed (LF) thus (CRLF). when you get code from git that was uploaded from a unix system they will only have an LF.

If you want to turn this warning off, type this in the git command line

git config core.autocrlf true

If you want to make an intelligent decision how git should handle this, read the documentation

Here is a snippet

Formatting and Whitespace

Formatting and whitespace issues are some of the more frustrating and subtle problems that many developers encounter when collaborating, especially cross-platform. It’s very easy for patches or other collaborated work to introduce subtle whitespace changes because editors silently introduce them, and if your files ever touch a Windows system, their line endings might be replaced. Git has a few configuration options to help with these issues.

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 4

This line of code should prevent this warning:

git config core.autocrlf false

If you want a more detailed answer as how and where you enter that line of code, look here: https://stackoverflow.com/questions/3841140/git-how-to-get-rid-of-the-annoying-crlf-message-on-msysgit-windows