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:
Configure git on my machine (OS X) to absolutely refuse anything CRLF.
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.
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.
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.