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

Question

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?

question from:https://stackoverflow.com/questions/8651708/git-adding-files-to-repository-gives-fatal-error-for-lf-crlf

Answer 1

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.