Blog Archive

Tag Cloud

Normalized Line Endings in Git

Git is immensely powerful, versatile, and (for an open source project like Moai) inevitable, but every now and then the wheels come off the wagon and using Git feels something like this:

When we first started with Git, we followed the popular advice to rely on autocrlf to handle our line engine conversions: on OSX and Linux, autocrlf=input and on Windows autocrlf=true. In spite of ensuring that all our machines and global config files were set up properly, we still had problems. Because of this I decided to instead use .gitattributes to enforce the correct line endings policy on .c, .cpp, .h and .lua files.

This has been a small struggle, but I think we've finally gotten to a place where all the files in the repo really are normalized to LF and will convert to whatever your core.eol is set to on checkout. (On my machine it appears that core.eol defaults to LF on Windows. I had to explicitely set it to 'crlf' to make it behave).

You can check the value of core.eol like this:

git config --global core.eol

If core.eol is the 'default' value then you will not see anything.

You can set your core.eol like this:

git config --global core.eol crlf

Even though we thought we had enabled normalization by setting up autocrlf, we discovered that our repository was full of files with crlf and (worse) mixed line endings. So after adding the 'text' attribute to all the file types we cared about in .gitattributes, we manually converted all the files to use LF (it's been seemingly impossible for us to verify that Git is doing this - but I won't go into that; all the files should be normalized now).

So, be aware: if you have made a bunch of local changes you may see a conflicts and local modificatons when you pull the next version of Moai from master. You may need to update your own files to use the correct line endings for your system and/or use a merge tool (like Git's) that can ignore line ending differences.

I will be waiting to hear the screams of anguish and frustration and hope we can find a way to help. Even if the change is painful, with any luck we'll be 'over the hump' now that the correct policies are in place at the repo level.