Why do I get CRLF line breaks in source files, although I'm on a Mac+Linux-only environment with Git and IDEA?
Asked Answered
R

1

10

My boss and I are the only ones working on our project and we use Macs exclusively for development. We are doing groovy/grails development, and deploy to Linux servers. There is no use of MS Windows involved anywhere in our development process whatsoever, yet somehow, when I'm diffing files with git in the bash shell, I end up seeing those stupid ^M characters that signify CR (and together with a line feed, CRLF).

This is appearing in files out of nowhere.

I searched online for where to set IntelliJ IDEA to use only LF as line ending but couldn't find it. The difficulty of googling answers about IDEA has compounded my frustration here.

I want to do these things:

  1. Configure git on my machine (OS X) to absolutely refuse anything CRLF.

  2. Also, I'm using gitolite as the access layer for our central repository server (which is Ubuntu Linux). If it's possible to enforce refusal of CRLF in gitolite, so much the better.

  3. Configure IntelliJ IDEA to never save anything as CRLF. If possible, even make it so that for existing files full of CRLF, if I add so much as a space and hit save, all CRLF are stripped out (converted to single LF).

I consider myself to be very proficient with Git generally, but I am horribly confused by all the configuration around CRLF. Can someone tell me what all of these settings should be for someone in my position?

The main point here is in a purely *nix/LF-line-ending environment I don't want to deal with any CRLF nonsense. This should be an absolute non-problem, and I hate dealing with it (in case you couldn't tell).

I want CRLF out of my life forever, please.

Ressieressler answered 13/8, 2011 at 18:24 Comment(0)
G
14

Locally, use git config --global core.autocrlf input. This will translate all CRLF's to LF's upon commit. I don't know of a way to configure this on gitolite, and the only line ending setup I know of in IntelliJ is one that lets you specify what to use for new files. It's in Settings at Code Style -> General toward the bottom of the dialog.

After changing your core.autocrlf setting, you can flush out all of the bad line endings by (starting with a clean working tree) deleting all tracked files and doing a git reset --hard to bring them back into existence. Then any files with bad line endings will be marked as "modified", and you can commit them to fix the line endings.

Goodygoody answered 13/8, 2011 at 18:44 Comment(5)
I think the problem was that I had core.autocrlf set to true. I'm not sure what my thinking was setting this before, but once I got rid of that it was ok.Ressieressler
Also ensure the Settings->Code Style->General pane has "Unix and OS X (\n)" set for "Line separator (for new files)".Stercoraceous
thanks.. this worked. I'm using AndroidStudio, imported a windows project and marked every source with this.Britzka
I can't get this solution to work, even following all the steps above, and also when I follow the steps detailed in help.github.com/articles/dealing-with-line-endings, with a .gitattributes file. My CRLF files remain stubbornly CRLF and Git doesn't seem to pick up on the difference.Camenae
this works well when we got trouble with switching macOS and WindowsGertie

© 2022 - 2024 — McMap. All rights reserved.