1

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.

trysis
  • 7,124
  • 12
  • 47
  • 74

3 Answers3

0

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.

trysis
  • 7,124
  • 12
  • 47
  • 74
-1

In your .gitattributes, just add this line. It will always convert all line ending to CRLF when checkout no matter what it was before.

* text eol=crlf

see this http://git-scm.com/docs/gitattributes

Set to string value "crlf"

This setting forces Git to normalize line endings for this file on checkin and convert them to CRLF when the file is checked out.

palazzo train
  • 2,657
  • 1
  • 13
  • 35
  • I believe `text=auto` is the same as "`eol=lf` or `eol=crlf` or whatever `git` feels like setting `eol` to at the time". Setting `eol=lf` didn't stop the error either way. Plus, I already read that page and that's partially why I started setting all these options. – trysis Sep 23 '14 at 14:03
  • Also also, I want `git` to convert my files to CRLF on checkout, because I'm on a Windows machine. – trysis Sep 23 '14 at 14:09
  • so setting text eol=crlf should be what you want, does it work for you? – palazzo train Sep 23 '14 at 14:12
  • No, that would check in as CRLF, which I don't want. Also, it still wouldn't help the errors. – trysis Sep 23 '14 at 14:18
  • You didn't miss my last line, as I added it after you added this answer. You did misinterpret it, however: see my previous comment. – trysis Sep 23 '14 at 14:20
  • You do not want to check in as CRLF, but as LF and when file checkout it converts to CRLF,right? May I know why eol=crlf does not work? "This setting forces Git to normalize line endings for this file on checkin and convert them to CRLF when the file is checked out." The git doc also said "When a text file is normalized, its line endings are converted to LF in the repository" – palazzo train Sep 23 '14 at 14:24
  • Sorry, I was confused by your description and forgot the actual meaning. It still doesn't stop the error, however. I believe the issue is with another setting I set somewhere. – trysis Sep 23 '14 at 14:31
  • Ah yes, my description was not corrected. I have edited again the answer to make it not so confusing. Regarding the FATAL error you've got, maybe set core.safecrlf to "warn". Someone discussed it before http://stackoverflow.com/questions/15467507/trying-to-commit-git-files-but-getting-fatal-lf-would-be-replaced-by-crlf-in Hope this helps. – palazzo train Sep 23 '14 at 14:36
  • I just answered with the `safecrlf` setting, which seems to have been the case. I appreciate your edit, but as it still doesn't answer the question, I'm still downvoting it. I'm thinking about closing this question anyway, however. – trysis Sep 23 '14 at 14:54
-2

git config autocrlf <option>

It can have options:
1) true:             x -> LF -> CRLF
2) input:            x -> LF -> LF
3) false:            x -> x -> x
Mudassir Razvi
  • 1,593
  • 10
  • 29
  • I have this setting set. I was playing with options, and tried unsetting it, setting/unsetting `core.safecrlf`, etc., but nothing worked. – trysis Sep 23 '14 at 13:37
  • I have edited my answer! It explains things and leaves you to decide! – Mudassir Razvi Sep 23 '14 at 13:38
  • It doesn't help. With all these options, I still get the error (just added to my question). Plus, you don't actually explain why these options would be helpful (not that they are in this case). – trysis Sep 23 '14 at 13:48