1799
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?

Mateen Ulhaq
  • 24,552
  • 19
  • 101
  • 135
LearningRoR
  • 26,582
  • 22
  • 85
  • 150
  • 60
    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 :) – Matt Greer Apr 29 '11 at 15:37
  • 1
    @Matt Greer Which means basically since i'm using Aptana Studios 3 IDE for Ruby on Rails it will cause this to happen? – LearningRoR Apr 29 '11 at 18:45
  • 5
    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. – Green Mar 21 '13 at 00:52
  • 15
    @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. – Ken Williams Dec 31 '13 at 16:56
  • 9
    If you are in a Unix system ```$ dos2unix file``` will fix this for you – ackuser Oct 03 '15 at 19:00
  • 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 !!! – sudeep_dk Nov 29 '15 at 04:19
  • 1
    Also, check if there has a .gitattributes file, if the content has *text=auto eol=crlf , delete this line . – hatanooh Oct 25 '19 at 02:19
  • Although I put autocrlf to true in the global config, the warning remains. – Timo Nov 11 '20 at 10:14
  • @MattGreer, actually, in Windows 10, since a release I don't know which, Notepad opens and displays Unix EOL "correctly". – René Nyffenegger Feb 09 '22 at 18:37

2 Answers2

2238

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
Shrage Smilowitz
  • 24,494
  • 2
  • 28
  • 32
  • 1
    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? – Mudaser Ali Apr 22 '13 at 14:37
  • 201
    Try this `git config --global core.safecrlf false` to disable warning and keep it functioning. I got this command from [here](http://stackoverflow.com/questions/6500880/git-turn-off-lf-will-be-replaced-by-crlf-warning). – Joel Handwell Feb 06 '16 at 12:27
  • 24
    `core.autocrlf true` does not turn off the warning for me, but `core.safecrlf false` as mentioned by Joel do. – Zitrax Mar 01 '16 at 15:40
  • git config core.autocrlf input for mac – Ankita Aug 25 '17 at 17:49
  • 7
    As @JoelHandwell mentioned, only `git config --global core.safecrlf false` suppressed my annoying warnings – James Poulose Oct 21 '17 at 20:31
  • 29
    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. – Bobort Jan 18 '18 at 15:31
  • 2
    @Bobort, from [git docs](https://git-scm.com/docs/gitattributes/1.7.3.3): 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. – Daynil Jan 21 '18 at 20:01
  • Ultimately, I decided to set it to `false` because my IDE, PyCharm, handles line endings automagically for me. – Bobort Jan 22 '18 at 21:31
  • 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. – domdaviesdev Jul 14 '18 at 15:08
  • 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. – Domske Oct 16 '18 at 14:38
  • 5
    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? – cowlinator Nov 08 '18 at 01:36
  • 1
    "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. – RBF06 Jan 29 '19 at 15:08
  • 3
    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. – Vytenis Bivainis Mar 27 '19 at 22:35
  • This helped me... 1)`git config --system --unset core.autocrlf` and then 2) `git config --global core.autocrlf true` From: http://wiki.opf-labs.org/display/SP/Configuring+how+line-endings+are+handled+by+git – Ryan Schultz Oct 14 '19 at 00:58
  • 1
    The message still appears even after running the command – ProsperousHeart Mar 25 '20 at 17:04
  • 7
    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. – Mark May 06 '20 at 14:13
  • What's the difference between the default behavior and setting the autocrlf true? – Akhila Jul 28 '20 at 22:52
  • 1
    @Mark 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 – gorhawk Jan 19 '21 at 20:23
  • 1
    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](https://stackoverflow.com/questions/6500880/with-git-how-do-i-turn-off-the-lf-will-be-replaced-by-crlf-warning) – Utmost Creator Jan 23 '21 at 15:58
  • I am working on GitHub and I found [this article](https://docs.github.com/en/github/getting-started-with-github/getting-started-with-git/configuring-git-to-handle-line-endings) helpful. It describes the config of git autocrlf and the setting .gitattributes file. – Jeff May 27 '21 at 04:03
  • 1
    @JoelHandwell to actually **fix the issue**, instead of changing behavior as @Bobort 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. – Cameron Tacklind Dec 15 '21 at 07:25
  • i enter this in the `cmd prompt`, but still get the same error message. using `vscode` on a `windows10` machine... what next to do ? – D.L Feb 16 '22 at 09:35
  • Yes. This is working. Solved the issue by adding this command. Thanks a lot. – PHP Laravel Developer May 16 '22 at 11:37
  • Which command should I use to avoid issue working on Mac and Windows at the same time? Thanks – Bitwise DEVS Jun 08 '22 at 14:58
438

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
AntoineB
  • 4,535
  • 5
  • 28
  • 61
SG 86
  • 6,974
  • 3
  • 25
  • 34
  • 126
    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. – cavalcade Nov 13 '12 at 11:03
  • 23
    Doesn't work for me. I had `core.autocrlf false` to begin with. – Klas Mellbourn Aug 16 '13 at 13:21
  • 8
    yeah setting it to true is what initially gave me the warnings. – gollumullog Nov 19 '13 at 21:21
  • 18
    In [answer to the duplicate question](http://stackoverflow.com/a/20653073/237105) I described the difference between autocrlf=true, false and auto. Hope it helps. – Antony Hatchkins Dec 18 '13 at 08:33
  • 35
    My `git config core.autocrlf` is already set to `true` from the beginning, but the warnings still show up. – DLight Sep 14 '14 at 22:59
  • 26
    I found that completely removing `core.autocrlf` from the `.git/config` file solved the problem for me. – Drew Noakes Dec 15 '14 at 20:26
  • 14
    Confirmed what Drew just said. Removing "core.autocrlf" from .git/config and ~/.gitconfig fixed the issue. – Mauvis Ledford Jan 22 '15 at 23:31
  • 1
    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? – Gabriel Staples Jan 29 '18 at 06:18
  • 4
    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? – Gabriel Staples Jan 29 '18 at 06:23
  • 20
    `git config --global core.safecrlf false` to disable the warning, not the answer given – omikes Jan 31 '18 at 22:56
  • 5
    to keep autocrlf function but turn off warning, do `git config --global core.safecrlf false` – FrankZhu Apr 04 '19 at 18:43
  • 1
    Confirmed. It's backwards - true for warnings, false for silent. – Rex the Strange Sep 24 '19 at 19:29
  • Just to confirm that removing completely these lines **from both places** ~/.gitconfig and project folder .git/config works – Vladyn Jul 25 '20 at 12:42
  • I use wsl and commit and checkout the same code from both systems. Would be the best remove the autocrlf from config? – Timo Nov 11 '20 at 11:19
  • 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. – OLL Feb 05 '21 at 15:58
  • if warnings persist, check the settings in `git config --global core.autoclrf` and `cat .gitattributes` – CervEd Mar 06 '21 at 17:15
  • 1
    This solution works for me I'm windows user git config --global core.autocrlf false – infiniteLearner Oct 18 '21 at 12:23
  • 1
    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. – Par Nov 06 '21 at 03:45
  • 1
    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. – Cameron Tacklind Dec 15 '21 at 07:31
  • @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. – Dragas Mar 27 '23 at 12:41
  • @Dragas 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. – Cameron Tacklind Mar 27 '23 at 20:07