Some files at the BC source tree have CRLF endings, others have LF, and
probably some plain CR ("DOS", "UNIX", and "MAC" styles); git dares to
presume to know what format I want all my source codes to use.
The result is that it does then claim that because it did autoconversion
during pull, there is now some difference in between the workspace, and
master repository. Only way to restore sanity, and avoid hair loss is
to disable that feature entirely.
(No conversion happens during clone, but do happen during pull.)
How? Comment out (#) all lines with 'text' at the .gitattributes
Sure it will disable fancy diffing too, but sanity is more important.
I am writing this note, as apparently that file at the root of the bc-java source tree is coming from repository, and not created locally.
We are following roughly the advice here: https://help.github.com/articles/dealing-with-line-endings . There were recently a few java files in the repository with CRLF endings; they have been fixed. We expect the repository itself to contain only LF endings. If you are working on Windows, I advise you to set core.autocrlf = true, and perhaps core.eol = crlf (even though it should be the default) since there appear to still be some git clients that fail to choose the native EOL correctly when text=auto is set in .gitattributes .
My desktops are Fedora 18 Linux, but still somehow the system is very much confused of what kind of line endings it should do. Actually I personally hate the idea that source repository "knows" what format files should be.
I have never seen it working properly.
As to the substance of this issue, we will be sticking with the .gitattributes for the moment. It's working fine for us internally across Linux and Windows (once we sorted out some teething problems). We are fairly new to git, but from everything I've read about it, this has become the standard way to handle it. That file doesn't actually compel clients to do anything, it merely advises them of the conventions for this repository.