LF will be replaced by CRLF in git - What is that and is it important? [duplicate]

Question

git init
git add .

Gives the following warnings for many files:

The file will have its original line endings in your working directory. warning: LF will be replaced by CRLF in <filename>.

What's the difference between LF and CRLF? What should I do about the warnings?

Propellant

Nowadays just about any text editor or developer related tool you use will account for Unix/Windows line end differences. Except Notepad, but Notepad isn't so hot anyway :) – Estragon

@Matt Greer Which means basically since i'm using Aptana Studios 3 IDE for Ruby on Rails it will cause this to happen? – Propellant

Warning is not bad. Worse is a msg like this fatal: LF would be replaced by CRLF in Gemfile.lock, and git doesn't allow you to add a file. It is produced if you have safecrlf = true option set in any (global or local) .gitconfig file. Just hide it under comment if any. – Coincidence

@MattGreer it is still a huge problem - if you get the line endings wrong on a shebang line, for example, a linux kernel can think the entire script is on one line, and the entire script is therefore the name of some executable to run. Or nearly just as bad, that the executable is called "/usr/bin/perl\cM" or whatever. – Trent

If you are in a Unix system $ dos2unix file will fix this for you – Geisel

You are getting this message bcoz you have deleted some folder in your repo and added some same folders again with same name @same path ..... so solution is delete folders first and commit than add folders and than commit -- this solved my commit error. ex - i have deleted unwanted node module and onde again added some deleted nodemodule .. cheers !!! – Reilly

Also, check if there has a .gitattributes file, if the content has *text=auto eol=crlf , delete this line . – Frescobaldi

Although I put autocrlf to true in the global config, the warning remains. – Ric

@MattGreer, actually, in Windows 10, since a release I don't know which, Notepad opens and displays Unix EOL "correctly". – Celinecelinka

@RenéNyffenegger It was Windows 10 1809 released in Sept 2018 where Notepad handles LF line endings. Only 7.5 years after Matt Greer's comment. devblogs.microsoft.com/commandline/extended-eol-in-notepad – Lindsaylindsey

Answer 1

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 are a single developer working on a windows machine, and you don't care that git automatically replaces LFs to CRLFs, you can turn this warning off by typing the following 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

Flushing

but still if you turn off the the warnings if we copy a complete directory from svn export folder to git we have to upload all files is there any fix of it? – Galegalea

Try this git config --global core.safecrlf false to disable warning and keep it functioning. I got this command from here. – Summarize

core.autocrlf true does not turn off the warning for me, but core.safecrlf false as mentioned by Joel do. – Cedillo

git config core.autocrlf input for mac – Effect

As @JoelHandwell mentioned, only git config --global core.safecrlf false suppressed my annoying warnings – Laryngology

I think it should be stated that by setting core.safecrlf to false you are not "suppressing warnings." You are changing the behavior of how git checks in and checks out files, and it is that behavior that may or may not generate a warning. For me, I want it to be true because I am developing on Windows. However, I also wish to suppress the warnings, which is a hope that has no answer in this thread. – Oza

@Bobort, from git docs: If core.safecrlf is set to "true" or "warn", git verifies if the conversion is reversible for the current setting of core.autocrlf. For "true", git rejects irreversible conversions; for "warn", git only prints a warning but accepts an irreversible conversion. According to this, if your preferred behavior is to reject irreversible conversions, there is no way to remove warnings without changing behavior. If you do not need such enforcement, setting core.safecrlf to false suppresses the warning, but still auto converts. – Linder

Ultimately, I decided to set it to false because my IDE, PyCharm, handles line endings automagically for me. – Oza

Thank you still works in 2018 on Windows 10 with gitbash and running Rails 5.1. I set mine to true as above which hides the messages and carries on doing the conversion in the background. – Zarzuela

You can also turn off the warning by setting to false. But this is not the question. I set it to false. So git does not touch the files. Is this correct? Idk. I have hybrid binary text files with LF. And I want that this ending type is not touched by git. – Aulos

The error message makes no sense though. I'm on windows and have autocrlf set to true. I am trying to add files containing LF to my index, but git is warning me that warning: LF will be replaced by CRLF. Shouldn't it be more like verbose: LF will be replaced by LF? Only when my local files contain CRLF and I add them to the index, or when I check out files containing LF, is there any conversion. Right? – Dilution

"when you get code from git that was uploaded from a unix system they will only have an LF" -- A properly maintained git repo will always use LF for the line endings in the actual repo and leave it to the user to configure how line ending conversion should be handled in the worktree. – Stave

They have that warning "LF will be replaced by CRLF in file.txt." or "CRLF will be replaced by LF in file.txt." WHEN? Adding to the index? Checking out? They don't say it!! They say what they will do (and they are not sure about that since they don't know if I will checkout or change my core.autocrlf), but they don't say what they have already done! They'd better say what they have ALREADY done, like "I replaced ... in the index." I think that's one of the reasons why it's so hard to understand. – Inclusive

This helped me... 1)git config --system --unset core.autocrlf and then 2) git config --global core.autocrlf true From: wiki.opf-labs.org/display/SP/… – Dimeter

The message still appears even after running the command – Windywindzer

The warning asked about in this post states that "LF will be replaced by CRLF", but the scenarios described in this answer all involve replacing CRLF with LF (or doing nothing). I understand the behavior of the setting, but it doesn't explain the warning at all. – Clino

What's the difference between the default behavior and setting the autocrlf true? – Hesperidium

@Clino exactly, moreover, I have a script that always generates the same git repo, and that script warns me every time on linux and there is no warning on windows, both systems have safecrlf set to false.. If anything, it should be the other way around – Icon

Linux / macOS systems use LF (linefeed) endings Windows uses CRLF (carriage-return LF) This one command is useful for Windows users git config --global core.autocrlf true Converts LF to CRLF. This one is useful for Linux or macOS users git config --global core.autocrlf input Converts CRLF to LF. To suppress the warning message and keep it working: git config --global core.safecrlf false (It only turns off the warning, not the function itself) I lended it from here – Firsthand

I am working on GitHub and I found this article helpful. It describes the config of git autocrlf and the setting .gitattributes file. – Eudemonism

@JoelHandwell to actually fix the issue, instead of changing behavior as @Oza mentioned, change your editor to use your system's line endings and/or delete files in working directory and git reset --hard to get the currently configured line endings. Git is leaving the files on your system as they are to be nice so you'll keep getting the warning until you fix the files. Or, if you really want non-system-native line endings, adjust core.eol for the whole repo, or use .gitattributes to do so on a file by file basis. – Irish

i enter this in the cmd prompt, but still get the same error message. using vscode on a windows10 machine... what next to do ? – Coomer

Yes. This is working. Solved the issue by adding this command. Thanks a lot. – Senhor

Which command should I use to avoid issue working on Mac and Windows at the same time? Thanks – Cristincristina

Answer 2

If you want, you can deactivate this feature in your git core config using

git config core.autocrlf false

But it would be better to just get rid of the warnings using

git config core.autocrlf true

Lichfield

hmm weird, I just set core.autocrlf to true (and confirmed the git cli command returns the status as true). however I still get the warnings. – Scaly

Doesn't work for me. I had core.autocrlf false to begin with. – Sovereignty

yeah setting it to true is what initially gave me the warnings. – Wrennie

In answer to the duplicate question I described the difference between autocrlf=true, false and auto. Hope it helps. – Trivet

My git config core.autocrlf is already set to true from the beginning, but the warnings still show up. – Soilure

I found that completely removing core.autocrlf from the .git/config file solved the problem for me. – Potomac

Confirmed what Drew just said. Removing "core.autocrlf" from .git/config and ~/.gitconfig fixed the issue. – Creek

I have confirmed in Windows at least for me that this answer has it backwards: git config core.autocrlf false gets rid of the warnings, and git config core.autocrlf true puts them there. Here is a sample warning: warning: LF will be replaced by CRLF in Windows_driver/RTWLANU_Driver/WinXP/rtlCoInst.dat. The file will have its original line endings in your working directory. I don't know what that means. Which is my "working directory" in this case? – Sheet

Also, my warning above is present when core.autocrlf is true. The warning seems to be worded wrong. Instead of saying warning: LF will be replaced by CRLF (which is what it does say) shouldn't it say warning: LF will replace CRLF, or equivalently, warning: CRLF will be replaced by LF? The warning seems to be backwards. Am I correct in correcting it by rewording it as above or am I mistaken? – Sheet

git config --global core.safecrlf false to disable the warning, not the answer given – Cosecant

to keep autocrlf function but turn off warning, do git config --global core.safecrlf false – Pelagic

Confirmed. It's backwards - true for warnings, false for silent. – Speedball

Just to confirm that removing completely these lines from both places ~/.gitconfig and project folder .git/config works – Bracci

I use wsl and commit and checkout the same code from both systems. Would be the best remove the autocrlf from config? – Ric

I had to do this to mute the warning: git config core.autocrlf false and then git config core.eol lf. This make git assume that you're using LF on Windows, which is what I wanted. – Ardenardency

if warnings persist, check the settings in git config --global core.autoclrf and cat .gitattributes – Onida

This solution works for me I'm windows user git config --global core.autocrlf false – Elm

Yes this is what i'd suggest, just deactivate. Set your IDE or code editor to use LF endings, and then set this to false. Problem solved. – Cantu

If you're on Windows, your editor should probably be set to CRLF line endings. If not, you'll get theses warnings because the next time git modifies those files it will update the line endings and change the file without telling you. It won't otherwise do it for you so it's warning you now and will keep warning until it's fixed. If you really want LF line endings on Windows, tell git with git config core.eol lf. If you just want some files to be Linux style, use .gitattributes to control the eol on a file by file basis and keep it consistent across copies of the repo. – Irish

@CameronTacklind you must be using lf line endings regardless of platform. All the editors deal with it properly sans notepad, and it's only windows (plus powershell, but powershell also outputs utf16 or utf8 bom depending on command so that's another topic) insisting on adding cr to every line end, breaking every script that you would copy over from windows hosts to unix based destinations. – Triley

@Triley No. Windows users and it's programs are supported in projects I work on. Windows software expects CRLF line endings. Sure, many tools now accept just LF line endings and can often even be configured to write text out with LF line endings. It does not break scripts if they are written for Windows. All file copying scripts that supports transfer between platforms support a text mode which automatically translates line endings. In my experience, trying to force all my dev tools on Windows to use only LF is more trouble than helpful. Just let git translate line endings. – Irish

Lots of people confused about the warning thinking it back to front. It isn't. If you have core.autocrlf true, and you're on Windows and you have a file with LF line endings that you git add, you will get the warning. That is, Git is telling you it will change the line ending from LF to CRLF when you commit. – Lindsaylindsey

@Triley No. You can't count on every Windows tool and app handling LF. You can count on them handling CRLF. Consider managing Windows hosts, but your CI/CD uses a Linux build agent running Ansible that copies files (say SQL files) to a Windows host. You don't run the Sql on Linux. You run it on the Windows target. In that case you don't even want your Linux machine checking out LF, coz it will then copy to your Windows host as LF which will break some tools. PowerShell does not output an encoding. It depends on the Shell. Sure it would be easier if Windows was the same as Linux but it isn't. – Lindsaylindsey