Why does commenting out the line for text files' LF normalization (in .gitattributes file) fix the problem of Visual Studio detecting line ending changes, and what will it affect to other developers' branches?
Scenario: I came across with an issue regarding Visual Studio detecting changed files which I didn't do any changes. When compared, Visual Studio would not show any difference. Then I found information here: Visual Studio Team Explorer is listing changes to files I didn't make, which led me to read on more about how Git manages the files' line endings here: What's the best CRLF (carriage return, line feed) handling strategy with Git?.
Turns out, the project has already setup a .gitattributes file in the root directory, which supposedly already fixed the problem on line endings I have read more about .gitattributes here: http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/.
Which led me to try and comment a line in the .gitattributes file that suppose to tell Git to do CRLF to LF replacement and vice versa:
*.js text
This change fixed the weird files that VS detected changes which I did not make. At this point however, there is that uncertainty of what effects would it bring to other developers' local/remote branches, and why is it happening. When I uncomment the *.js text, the detected weird files would show up again.
I have a vague understanding that what I am seeing is the "read" part, or the LF to CRLF conversion, but what will be its effects when I push the commenting of this line is unknown to me, whether it would help the whole team get rid of the problem or will it spawn more line ending related problems.
