258

env:

  • Windows 7
  • msysgit

Wheng I git commit, it says:

warning: LF will be replaced by CRLF. 

Is this warning tail backward?
I edit file in Windows, the end of line is CRLF, just like this pic:
enter image description here
And git changes it to LF for committing to repo.
So I think the correct warning is:

warning: CRLF will be replaced by LF. 
Honghe.Wu
  • 5,899
  • 6
  • 36
  • 47
  • Also see http://stackoverflow.com/questions/1598260/make-crlf-warnings-go-away and http://stackoverflow.com/questions/5834014/lf-will-be-replaced-by-crlf-in-git-what-is-that-and-is-it-important – devnull Jul 13 '13 at 08:26
  • 2
    @devnull I mean the warning is tail backward, is it? – Honghe.Wu Jul 13 '13 at 12:22
  • @Honghe.Wu No, it isn't on Windows. I have edited [my answer below](http://stackoverflow.com/a/17628353/6309) – VonC Jul 13 '13 at 12:50
  • 21
    Great question because indeed, the warning seems to be backward. It's really confusing to get this warning about converting **to CRLF** on a **commit** and no amount of explaining Git's handling of whitespace will help, because the warning is *backwards*. – Stijn de Witt Mar 17 '16 at 13:23
  • @user1460043 Feel free to upvote the comment :) But I don't think the confirmation of fact is worthy of an answer. It's just a bug in Git for Windows. Someone just should report it (or even better, fix it) – Stijn de Witt Jun 29 '16 at 23:58
  • I had the exactly same warning in a file without a change, see https://stackoverflow.com/questions/44305307/git-filter-not-unmodifying-file/44458163#44458163. Staging this particular file got the warning and error resolved. – maxik Jun 09 '17 at 12:50
  • I had the same issue with using Cmder. – saurav.varma Apr 30 '19 at 04:45
  • Does this answer your question? [git replacing LF with CRLF](https://stackoverflow.com/questions/1967370/git-replacing-lf-with-crlf) – kenorb Jun 25 '20 at 17:34

13 Answers13

330

warning: LF will be replaced by CRLF.

Depending on the editor you are using, a text file with LF wouldn't necessary be saved with CRLF: recent editors can preserve eol style. But that git config setting insists on changing those...

Simply make sure that (as I recommend here):

git config --global core.autocrlf false

That way, you avoid any automatic transformation, and can still specify them through a .gitattributes file and core.eol directives.


windows git "LF will be replaced by CRLF"

Note: the warning message has changed with Git 2.37 (Q3 2022)

Is this warning tail backward?

No: you are on Windows, and the git config help page does mention

Use this setting if you want to have CRLF line endings in your working directory even though the repository does not have normalized line endings.

As described in "git replacing LF with CRLF", it should only occur on checkout (not commit), with core.autocrlf=true.

       repo
    /        \ 
crlf->lf    lf->crlf 
 /              \    

As mentioned in XiaoPeng's answer, that warning is the same as:

warning: (If you check it out/or clone to another folder with your current core.autocrlf configuration,) LF will be replaced by CRLF
The file will have its original line endings in your (current) working directory.

As mentioned in git-for-windows/git issue 1242:

I still feel this message is confusing, the message could be extended to include a better explanation of the issue, for example: "LF will be replaced by CRLF in file.json after removing the file and checking it out again".

Note: Git 2.19 (Sept 2018), when using core.autocrlf, the bogus "LF will be replaced by CRLF" warning is now suppressed.


As quaylar rightly comments, if there is a conversion on commit, it is to LF only.

That specific warning "LF will be replaced by CRLF" comes from convert.c#check_safe_crlf():

if (checksafe == SAFE_CRLF_WARN)
  warning("LF will be replaced by CRLF in %s.
           The file will have its original line endings 
           in your working directory.", path);
else /* i.e. SAFE_CRLF_FAIL */
  die("LF would be replaced by CRLF in %s", path);

It is called by convert.c#crlf_to_git(), itself called by convert.c#convert_to_git(), itself called by convert.c#renormalize_buffer().

And that last renormalize_buffer() is only called by merge-recursive.c#blob_unchanged().

So I suspect this conversion happens on a git commit only if said commit is part of a merge process.


Note: with Git 2.17 (Q2 2018), a code cleanup adds some explanation.

See commit 8462ff4 (13 Jan 2018) by Torsten Bögershausen (tboegi).
(Merged by Junio C Hamano -- gitster -- in commit 9bc89b1, 13 Feb 2018)

convert_to_git(): safe_crlf/checksafe becomes int conv_flags

When calling convert_to_git(), the checksafe parameter defined what should happen if the EOL conversion (CRLF --> LF --> CRLF) does not roundtrip cleanly.
In addition, it also defined if line endings should be renormalized (CRLF --> LF) or kept as they are.

checksafe was an safe_crlf enum with these values:

SAFE_CRLF_FALSE:       do nothing in case of EOL roundtrip errors
SAFE_CRLF_FAIL:        die in case of EOL roundtrip errors
SAFE_CRLF_WARN:        print a warning in case of EOL roundtrip errors
SAFE_CRLF_RENORMALIZE: change CRLF to LF
SAFE_CRLF_KEEP_CRLF:   keep all line endings as they are

Note that a regression introduced in 8462ff4 ("convert_to_git(): safe_crlf/checksafe becomes int conv_flags", 2018-01-13, Git 2.17.0) back in Git 2.17 cycle caused autocrlf rewrites to produce a warning message despite setting safecrlf=false.

See commit 6cb0912 (04 Jun 2018) by Anthony Sottile (asottile).
(Merged by Junio C Hamano -- gitster -- in commit 8063ff9, 28 Jun 2018)

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 1
    Yes, most editors can preserve EOL style, but with most editors, that has no effect when creating a new file in the same project. Make sure you don't checkout a LF project, think "psh, my editor can handle LF line endings, I don't need autocrlf", and then forget to manually set new files to LF line endings. –  Jul 13 '13 at 09:04
  • So, given this warning, git is saying that it will store the file with crlf in the repository? – Chris Nov 28 '13 at 15:09
  • @Chris yes, which is to be avoided. Git shouldn't change eol unless explicitily instructed though a `.gitattributes core.eol` directive. – VonC Nov 28 '13 at 15:42
  • @VonC Is this correct?? The core.autocrlf directive will convert all crlf to lf upon commit and vice versa on checkout. So upon commit, the mentioned warning is in fact incorrect imho. – quaylar Feb 19 '14 at 13:05
  • @quaylar yes, it is correct for a '`native`' value of `core.autocrlf`: It converts to the eol of the platform. On windows, it is `CRLF`. – VonC Feb 19 '14 at 13:09
  • 18
    @VonC I must confess I am not getting it. The Git-Book states _Git can handle this by auto-converting CRLF line endings into LF when you commit, and vice versa when it checks out code onto your filesystem._ This means that on **commit** there will be a conversion to **LF** and never to **CRLF**. Which means that the mentioned warning is incorrect. Having `core.autocrlf=true` will **always** yield in LF in the repo, and CRLF in the working tree imho (even under non-Windows). Source: [link](http://git-scm.com/book/ch7-1.html#Formatting-and-Whitespace) – quaylar Feb 19 '14 at 13:34
  • @quaylar I agree with your interpretation. I have dig a bit deeper into the code of Git in order to see how/when this particular conversion would occur. See my edited answer. – VonC Feb 19 '14 at 15:08
  • @quaylar that's exactly the way I would see it. I think the warning should be changed to something like: ` has CRLF line endings - those will be converted to LF on commit. On checkout, these LF will be replaced by CRLF so that the file will have its original line endings in your working directory.` Does this make sense? – Hirnhamster Nov 30 '14 at 23:08
  • Just read another answer that explains it perfectly: http://stackoverflow.com/a/1967986/413531 (couldn't edit my previous comment any longer, sry) – Hirnhamster Nov 30 '14 at 23:15
  • 15
    "Is this warning tail backward? it should only occur on checkout" I am seeing this exact warning on **commit**. So **yes**, it is backward. It being backward triggered me searching for this. Glad others noticed it too! It is very confusing to people that actually read these warnings to see it saying it will convert to CRLF on a commit message. – Stijn de Witt Mar 17 '16 at 13:20
  • 7
    "So I suspect this conversion happens on a git commit only if said commit is part of a merge process." Nope. I am seeing this on regular commits. – Stijn de Witt Mar 17 '16 at 13:25
  • 5
    The part that bugs me about the message is that it pops up at all. why do I need to be WARNed that git is about to do exactly what I have configured it to do. I dont need a warning saying "hey, we are still converting line endings for you, like you asked us to". When the system is behaving by design, it shouldnt give unnecessary warnings, or people miss the important warnings in a sea of irrelevant messages. – Brent Larsen Apr 08 '16 at 18:04
  • 1
    "So I suspect this conversion happens on a git commit only if said commit is part of a merge process." - No (as observed by @StijndeWitt). To reproduce on Windows, create a new repo with core.autocrlf false and place a .gitattributes with `* text=auto !eol` in the working directory. Then the warning appears even on `git add`ing a text file that has LF as line endings. On `git commit` it appears as well. – user1460043 Jun 28 '16 at 13:53
50

YES the warning is backwards.

And in fact it shouldn't even be a warning in the first place. Because all this warning is saying (but backwards unfortunately) is that the CRLF characters in your file with Windows line endings will be replaced with LF's on commit. Which means it's normalized to the same line endings used by *nix and MacOS.

Nothing strange is going on, this is exactly the behavior you would normally want.

This warning in it's current form is one of two things:

  1. An unfortunate bug combined with an over-cautious warning message, or
  2. A very clever plot to make you really think this through...

;)

Stijn de Witt
  • 40,192
  • 13
  • 79
  • 80
  • 1
    What's strange is that if you forcibly convert local files on Windows to LF you cannot even git add the files, the message complains and voids your commit. – phpguru Nov 14 '16 at 18:55
  • *nix, I like that. – jacktrader Dec 07 '22 at 15:08
  • No, it's not. It's saying you had lf in your work tree content that you added, and the way you've got your repo set up now when you check that content out again, the lf you added will be replaced by a crlf. It could explain it better but it couldn't explain it different, the work tree lf hasn't changed, the repo has the lf unchanged, the only change will be in the future, on checkout, when the lf will be replaced by crlf. – jthill Aug 31 '23 at 16:51
30

NO. It is NOT talking about your files currently with CRLF. It is instead talking about files with LF.

It should read:

warning: (If you check it out/or clone to another folder with your current core.autocrlf configuration,)LF will be replaced by CRLF

The file will have its original line endings in your (current) working directory.

This picture should explain what it means. enter image description here

Community
  • 1
  • 1
Devs love ZenUML
  • 11,344
  • 8
  • 53
  • 67
  • What works well for me is: 1) core.autocrlf=false 2) in Intellij set Line separator (\n). I use Intellij Idea on both Mac and Windows. – Devs love ZenUML Jul 18 '17 at 01:26
  • 1
    This can happen when the file was created in Windows but has a unix/mac line ending (lf) and your git config property autocrlf is true. Essentially git isn't going to change the file you created but it will check it out/clone it with windows line endings (because of your autocrlf setting) – Patrick Aug 07 '18 at 04:04
  • 1
    How is the warning correct and accurate if you have to qualify it with "If you check it out/or clone to another folder with your current core.autocrlf configuration". That isn't what the original message says. It says it WILL (not might) be replaced by CRLF, implying that it will be stored in CRLF mode in the repo itself, not in some hypothetical future checkout. – mgiuca Jun 25 '19 at 11:43
18

All of this assumes core.autocrlf=true

Original error:

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

What the error SHOULD read:

warning: LF will be replaced by CRLF in your working directory
The file will have its original LF line endings in the git repository

Explanation here:

The side-effect of this convenient conversion, and this is what the warning you're seeing is about, is that if a text file you authored originally had LF endings instead of CRLF, it will be stored with LF as usual, but when checked out later it will have CRLF endings. For normal text files this is usually just fine. The warning is a "for your information" in this case, but in case git incorrectly assesses a binary file to be a text file, it is an important warning because git would then be corrupting your binary file.

Basically, a local file that was previously LF will now have CRLF locally

Community
  • 1
  • 1
mikew
  • 1,634
  • 2
  • 15
  • 25
13

git config --global core.autocrlf false works well for global settings.

But if you are using Visual Studio, might also need to modify .gitattributes for some type of projects (e.g c# class library application):

  • remove line * text=auto
Eric
  • 22,183
  • 20
  • 145
  • 196
  • 1
    Wish this was higher in the thread. I suspect that since a decade ago when the top comment was written most users will have switched to vscode, making this solution far more relevant. – Maile Cupo May 18 '23 at 20:41
10

This happens because the configuration for GitHub Desktop on Windows assumes CRLF but the text editor may be using LF. You can change your local repository settings to use lf instead.

Navigate to the root of the git repo and execute this in exact same order

git config core.eol lf
git config core.autocrlf input

Source: GitHub issue

avp
  • 2,892
  • 28
  • 34
3

After I set core.autocrlf=true I was getting "LF will be replaced by CRLF" (note not "CRLF will be replaced by LF") when I was git adding (or perhaps it was it on git commit?) edited files in windows on a repository (that does use LF) that was checked out before I set core.autocrlf=true.

I made a new checkout with core.autocrlf=true and now I'm not getting those messages.

Nick F
  • 9,781
  • 7
  • 75
  • 90
3

Is this warning tail backward?

The warning is first and foremost confusing.
Git 2.37 (Q3 2022) rewords and clarifies it.

See commit c970d30 (07 Apr 2022) by Alex Henrie (alexhenrie).
(Merged by Junio C Hamano -- gitster -- in commit 0a88638, 20 May 2022)

convert: clarify line ending conversion warning

Signed-off-by: Alex Henrie

The warning about converting line endings is extremely confusing.

LF will be replaced by CRLF in ...
The file will have its original line endings in your working directory.

Its two sentences each use the word "will" without specifying a timeframe, which makes it sound like both sentences are referring to the same timeframe.
On top of that, it uses the term "original line endings" without saying whether "original" means LF or CRLF.

Rephrase the warning to be clear about when the line endings will be changed and what they will be changed to.

On a platform whose native line endings are not CRLF (e.g. Linux), the "git add"(man) step in the following sequence triggers the new message in question (no more warning):

$ git config core.autocrlf true 
$ echo 'Hello world!' >hello.txt 
$ git add hello.txt 

In the working copy of 'hello.txt', CRLF will be replaced by LF 
the next time Git touches it.

And on a platform whose native line endings are not LF (e.g. Windows), the "git add"(man) step in the following sequence triggers the new message in question (no more warning):

$ git config core.autocrlf true 
$ echo 'Hello world!' >hello.txt 
$ git add hello.txt 

In the working copy of 'hello.txt', LF will be replaced by CRLF 
the next time Git touches it.
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

I faced similar issue and using vscode(v1.57) on windows tried solutions defined in other answers but didn't worked.

So for me following steps worked:

  1. In root folder there is a file named .editorconfig
  2. open this file and change end_of_line = lf with end_of_line = crlf
  3. run git rm --cached and warning gone!!
Dharman
  • 30,962
  • 25
  • 85
  • 135
Ajay
  • 458
  • 4
  • 20
0

Make sure you added unnecessary files or folders in .gitignore file.

e.g. node_modules

if still face then run this command

``git config --global core.autocrlf false```

GMKHussain
  • 3,342
  • 1
  • 21
  • 19
0

I was playing minecraft game, and while uploading world files on github, I got this error.

When I closed game then tried to upload again, it worked fine as some session.lock file was used by game which prevents other task from accessing these files.

-1

Do just simple thing:

  1. Open git-hub (Shell) and navigate to the directory file belongs to (cd /a/b/c/...)
  2. Execute dos2unix (sometime dos2unix.exe)
  3. Try commit now. If you get same error again. Perform all above steps except instead of dos2unix, do unix2dox (unix2dos.exe sometime)
kenorb
  • 155,785
  • 88
  • 678
  • 743
Antriksh Jain
  • 231
  • 2
  • 3
-4

Close Visual Studio

If you get the error, a simple fix is closing Visual Studio and you can commit to main, it is that easy. I had this same problem and that was how I fixed it. It is caused because the files you want to open are open in another programm.