Preparing a Windows Git Repo for Cross-Platform Development

Question

I have a Git repo that until now was primarily used for Windows development. Most aspects of the Git EOL issues (LF vs. CRLF) were not significant and development proceeded without hindrance.
Having moved to a CMake build environment, I want to build the code on UNIX/Linux/MacOS. The code itself is portable but from past experience and some initial experiments, the transition is somewhat painful with Git marking whole directories on untouched files as modified, detects seemingly unmodified lines within files and screwing up case-[in]sensitive file/folder names.

Additionally, it seems that as of Git 1.7.2, Git has a new EOL system based on the local, per-project, checked-in, .gitattributes instead of the, per-user, global, .gitattributes that each use on each platform should set.

Can anyone suggest a repo preparation path/process (on Windows) that will allow me to pull and commit files on Linux without all these troubles?

A partial suggestions can be seen, e.g. here, but that is too brute force and does not take into account files that the .gitattributes specifically intended to leave as-is (e.g. *.sln)

Answer 1

I use Notepad2, with that you can change the default Line Endings to Linux (LF).

If I understand correctly, there is not real need to change the source files to have LF on Windows machines. Although Git checks them in with LF, they can be checked out with CRLF on Windows.

To me this is a big no no. When using git I want to check out exactly what is in the repo. I see no reason to have git convert line endings when any decent Windows text editor will allow you to choose default Line Endings. I do not and will not allow git to mess with Line Endings.

Answer 2

In general, do not automatically convert data before storing it in a VCS (autocrlf=false in git IIRC), otherwise you will get false positives about the data having changed when it didn't. Leave any "interpretation" of what the data means to tools outside the VCS (editor, etc).

To prevent spurious newline changes, consider:

• Setting up some kind of pre-commit hook that rejects any commits with changes that consist of only rewritten newlines.
• Protecting only those few files that might be sensitive to newline changes (.sln, .vc* files etc).
• Figure out what editors your team is using, and make sure everyone has them configured so that they don't spuriously rewrite newlines. (Most editors are already setup this way by default - so you won't have a problem until someone takes it upon themselves to have their editor rewrite them.)