Git, adding files to repository gives fatal error for LF ->CRLF

L

4

41

I'm new to git and I need some help. I'm using msysgit on windows.

When I execute the command git add [folderName] I get the response:

fatal: LF would be replaced by CRLF in [.css file or .js file]

and then if you try to do a commit nothing happens.

$ git commit
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       so01/
nothing added to commit but untracked files present (use "git add" to track)

Some of these css/js files were downloaded from the net so I guess that's why the have LF. If I open the file and cut/paste the content, then I get the error on the next file and so on.

Any help will be much appreciated.

Edit

Setting core.autocrlf to false seems to solve the problem, but I read on many posts not to set this option to false.

Can somebody point me where can I find out what problems may arise in this situation?

Lecythus answered 28/12, 2011 at 4:2 Comment(3)

Are you working with others that are on a non-windows environment? – Goosefish 28/12, 2011 at 20:42

No. I am working on a small app that I will put on appharbor. So far everything is good, but I wanted to know what's the difference in those options. After i finish the app i do plan to do some reasrch but in the mean time i though i'll use SO for a quick solution. – Lecythus 29/12, 2011 at 0:36

Then all the more reason to set autocrlf to false. You don't need the headache. Have the files committed as is. It's too bad that the default settings when installing msysgit take the worst option. – Goosefish 29/12, 2011 at 1:2

G

22

Trust the code editors to manipulate your line endings. Auto crlf should be false. Don't let source control get too smart. If don't need to have your source control tool to change your line endings, don't. This will hurt.

To reiterate from an accepted answer: "Unless you can see specific treatment which must deal with native eol, you are better off leaving autocrlf to false."

Also from the progit book at the end of the section on autocrlf:

"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"

The only other help I can give is that if you take the other route, get familiar with vim -b which will show special characters such as the CR in MSysGit, and git show HEAD:path/to/your/file.txt which should show you the file in the way that git stored it.

Set core.whitespace cr-at-eol to have patches and diffs not highlight CRs as possible problematic whitespace.

Not worth the hassle. Store as-is.

Goosefish answered 28/12, 2011 at 6:34 Comment(7)

Auto crlf should be false <-- This is not true on windows – Hamo 28/12, 2011 at 12:39

yes it is true on windows. Again, don't do anything but autocrlf = false. I've been doing this for the last 4 years with multiple teams in windows/.net. You can do other stuff to fall and hurt yourself. You will eventually set autocrlf to false. – Goosefish 28/12, 2011 at 20:37

Why is your anecdotal evidence specific to windows/.net more important than others and what is recommend in progit.org/book/ch7-1.html? – Hamo 29/12, 2011 at 2:59

It's still anecdotal, my view point as a primary Windows user working in teams where multiple operating systems are used is that the documentation is correct and it very much depends on the repository. Blindly setting core.autocrlf to false is not the kind of advice you should be dealing out, it is simply misinformation. – Hamo 29/12, 2011 at 6:2

read his comments. He's the only one using his solution and is windows only. There absolutely no need for him to have any transformations being done for him. Further, cross-platform development is the exception not the rule - especially to anyone using msysgit. This is hardly misinformation. – Goosefish 29/12, 2011 at 6:20

+1 to counter downvote: this answer makes perfect sense. @prusswan: please re-read the Pro Git page you yourself have linked to. It specifically says "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." Unless you can point to some specific examples of cases where autocrlf=false has actually caused problems in a Windows-only environment, any instruction to set it to true is just cargo cult advice. – Retire 29/12, 2011 at 11:18

The OP stating it is a windows only project is not a plausible reason to to advokate that core.autocrlf=false should always be used. I hardly understand your reasoning that cross-platform development is the exception to the rule, many developers will participate on projects with different architectures, especially in the Java world where not using core.autocrlf=false does become troublesome as editors fight for the line-ending. Visual Studio also has the addded annoyance that it only changes line-endings to the portions of the files you edit and not the whole file. – Kreitman 4/7, 2012 at 12:12

H

24

very new to this so setting core.autocrlf to false didn't make too much sense to me. So for other newbies, go to the config file in you .git folder and add:

[core]
    autocrlf = false

under the [core] heading.

Hemorrhage answered 26/7, 2012 at 19:15 Comment(0)

G

22

Trust the code editors to manipulate your line endings. Auto crlf should be false. Don't let source control get too smart. If don't need to have your source control tool to change your line endings, don't. This will hurt.

To reiterate from an accepted answer: "Unless you can see specific treatment which must deal with native eol, you are better off leaving autocrlf to false."

Also from the progit book at the end of the section on autocrlf:

"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"

The only other help I can give is that if you take the other route, get familiar with vim -b which will show special characters such as the CR in MSysGit, and git show HEAD:path/to/your/file.txt which should show you the file in the way that git stored it.

Set core.whitespace cr-at-eol to have patches and diffs not highlight CRs as possible problematic whitespace.

Not worth the hassle. Store as-is.

Goosefish answered 28/12, 2011 at 6:34 Comment(7)

Auto crlf should be false <-- This is not true on windows – Hamo 28/12, 2011 at 12:39

yes it is true on windows. Again, don't do anything but autocrlf = false. I've been doing this for the last 4 years with multiple teams in windows/.net. You can do other stuff to fall and hurt yourself. You will eventually set autocrlf to false. – Goosefish 28/12, 2011 at 20:37

Why is your anecdotal evidence specific to windows/.net more important than others and what is recommend in progit.org/book/ch7-1.html? – Hamo 29/12, 2011 at 2:59

It's still anecdotal, my view point as a primary Windows user working in teams where multiple operating systems are used is that the documentation is correct and it very much depends on the repository. Blindly setting core.autocrlf to false is not the kind of advice you should be dealing out, it is simply misinformation. – Hamo 29/12, 2011 at 6:2

read his comments. He's the only one using his solution and is windows only. There absolutely no need for him to have any transformations being done for him. Further, cross-platform development is the exception not the rule - especially to anyone using msysgit. This is hardly misinformation. – Goosefish 29/12, 2011 at 6:20

+1 to counter downvote: this answer makes perfect sense. @prusswan: please re-read the Pro Git page you yourself have linked to. It specifically says "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." Unless you can point to some specific examples of cases where autocrlf=false has actually caused problems in a Windows-only environment, any instruction to set it to true is just cargo cult advice. – Retire 29/12, 2011 at 11:18

The OP stating it is a windows only project is not a plausible reason to to advokate that core.autocrlf=false should always be used. I hardly understand your reasoning that cross-platform development is the exception to the rule, many developers will participate on projects with different architectures, especially in the Java world where not using core.autocrlf=false does become troublesome as editors fight for the line-ending. Visual Studio also has the addded annoyance that it only changes line-endings to the portions of the files you edit and not the whole file. – Kreitman 4/7, 2012 at 12:12

S

6

The problem is probably occurring because you set Git to store files internally with crlf with the core.eol setting. When you add a file, Git is warning you it will change it to the internal format.

Git works best with lf line endings, so if possible always work with core.eol = lf.

This should explain when to use core.autocrlf, Why should I use core.autocrlf=true in Git?

You may also want to use core.safecrlf. Check git config --help for details on the settings.

Scrouge answered 28/12, 2011 at 12:7 Comment(2)

The answer you linked to states: "Unless you can see specific treatment which must deal with native eol, you are better off leaving autocrlf to false." – Goosefish 28/12, 2011 at 20:40

I'm not sure why I received a downvote for this? Have I missed something? @AdamDymitruk It also gives a couple of cases where it could be used. I think it's useful to know why the option it there (if I should never use it, why can I set it?) – Scrouge 29/12, 2011 at 11:45

O

0

The git autodetection of formats works pretty well. Therefore, core.autocrlf=true is a really good idea on Windows.

Saying git config --global core.safecrlf=false says to git: Hey, please convert my wrong line endings (LF only) to Windows line endings (CRLF) and do not bother me with it.

Therefore, you should really disable core.safecrlf.

Longer answer at: https://mcmap.net/q/21390/-trying-to-commit-git-files-but-getting-fatal-lf-would-be-replaced-by-crlf-in-lt-some-file-in-repo-gt

Odel answered 2/6, 2015 at 22:52 Comment(1)

@downvoters: Please shortly explain why you downvote this answer. This helps (i) others to understand why this answer has no votes and (ii) to improve the answer. – Odel 5/3, 2017 at 9:29

Recommended topics

Hot tags