CODEWITHSUNDEEP
gitversion-controlnewlinemsysgitcore.autocrlf
user619656
user619656

Reputation: 799

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

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?

Upvotes: 41

Views: 29428

Answers (4)

koppor
koppor

Reputation: 20521

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://stackoverflow.com/a/15471083/873282

Upvotes: 0

sigmapi13
sigmapi13

Reputation: 2533

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.

Upvotes: 24

Adam Dymitruk
Adam Dymitruk

Reputation: 129584

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.

Upvotes: 22

m0tive
m0tive

Reputation: 2946

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.

Upvotes: 6

Related Questions