Let me clarify: I want git to not care about whether line endings are CRLF or LF on checkin/commit. I understand there is no way at the moment to make git not care if a file has mixed line endings, although I would love a workaround to this, just in case; I just want it not to care whether all line endings in a file are CRLF or LF.
I recently set many file extensions in my system .gitattributes file, /etc/gitattributes (using MSysGit), to tell git which extensions are usually text or binary. For most of the files I want git to think are text, I set the extension
*.extension text=auto
because this will tell git that files with these extensions should have the general system line endings. Now I am regretting that decision, as I am seeing how many files are, for one reason or another, automatically given LF line endings instead of CRLF. Now, after tinkering with this and other settings, I have been getting errors similar to
$ git add -A && git commit -m "signup/in/out now possible through passport"
fatal: LF would be replaced by CRLF in node_modules/mongoose/node_modules/ms/package.json
on a lot of files I try to check in. In this case, it seems to be npm that's causing these files to be created as LF instead of CRLF, but I'm sure there are many other causes.
To be honest, I personally don't care which type of line endings a specific file has, as long as I can read and edit these files in my editing tool(s) of choice, as the vast majority of the time the line endings don't have any special function besides being, well, line endings. If it really matters, I can always do a quick conversion with unix2dos or dos2unix. However, git is notoriously finicky with line endings, and I don't want it to accidentally mark a text file as binary or vice versa, hence why I have been changing all these defaults.
How do I make git check in all text files as LF-line-ended files, and check them out as CRLF, but not care whether they have CRLF or LF endings in my actual working tree? Alternatively, is there a way to have git convert all the text files with LF endings to CRLF in my working tree as well, instead of giving the warning and giving up?
EDIT It seems my issue was not with my gitattributes files, but with my core.safecrlf setting in my gitconfig.
My issue seems to be with another config setting I set in git, core.safecrlf. According to the accepted answer to this question, which clarified things in several blog posts on the subject, this setting checks to see if the files git is checking in or out will have their line endings changed. If it determines they will be changed, it aborts the operation. I didn't understand this setting before, but now that I've played around a bit, I think I do understand it.
From what I can tell by the playing around, it seems that this setting is only useful for binary files with extensions not specified in your gitattributes, as well as files where line endings actually have a meaning in the language you will be using to edit them. As an example, let's assume all files in this language have the extension .ext. If this language uses the symbol computers use to denote LF and/or the one they use to denote CRLF, git shouldn't convert these .ext files. I don't know of any languages like that, but if they exist, and if the programmer still wants git to interpret files written in these languages as text, the programmer should have a special attribute set in his/her gitattributes, instead of having *.ext text.
Other than these 2 types of files, I can't think of any other situation to use core.safecrlf=true. Therefore, until I encounter a situation like these, I will be having this setting unset, or perhaps set to warn.