If case case people do not have core.autocrlf set in git global configurations, let git handle the files in whatever way it thinks is best, which is a good default option. After .gitattributes is activated, refresh all source files with proper line encodings.
I would consider a .gitattributes change like this if this was a project with a large number of contributors.
The 32f8770 commit just touches too much code and creates a messy output for the blame command.
Most modern editors can handle either line ending type. My editor of choice certainly can and it even maintains the current format for new lines that it adds to an existing file.
I don't personally like the autocrlf feature of git. I prefer that files be stored and manipulated with specific line endings.
If case case people do not have core.autocrlf set in git global configurations, let git handle the files in whatever way it thinks is best, which is a good default option. After .gitattributes is activated, refresh all source files with proper line encodings.
Reference: https://help.github.com/articles/dealing-with-line-endings/