Handeling line ending in GIT

Question

Let's say we have team of 10 developers. Half of them use Windows and half Linux. All of them work together on a project, sharing work using GIT. Problem with CRLF/LF begins ...

Exmaple: One developer with Window works on the same thing together with developer which is using Linux. Both of them need to view/edit the same files.

Will there be problem with CRLF and LF ? What are the ways GIT would handle this problem ? (force Linux isn't solution)

Answer 1

You can see more with the recent article " Git for Windows: Line Endings " from Edward Thomson (Ex-GitHubber, now Microsoft, now... errr GitHubber again)

The key to dealing with line endings is to make sure your configuration is committed to the repository, using .gitattributes . For most people, this is as simple as creating a file named .gitattributes at the root of your repository that contains one line:

* text=auto

With this set, Windows users will have text files converted from Windows style line endings (\\r\\n) to Unix style line endings (\\n) when they're added to the repository.

Why not core.autocrlf ?

Originally, Git for Windows introduced a different approach for line endings that you may have seen: core.autocrlf . This is a similar approach to the attributes mechanism: the idea is that a Windows user will set a Git configuration option core.autocrlf=true and their line endings will be converted to Unix style line endings when they add files to the repository.

The difference between these two options is subtle, but critical: the .gitattributes is set in the repository, so its shared with everybody. But core.autocrlf is set in the local Git configuration. That means that everybody has to remember to set it, and set it identically.

I would add that core.autocrlf applies to all files including binaries ones, whereas .gitattribure core.eol directive can be set for specific files (like *.cpp for instance)

I have always recommended that .gitattributes approach .