updated .gitattributes to always use CRLF

[mousetraps]

I assumed text=auto would default to CRLF on Windows, but apparently that doesn't occur in all cases (namely, our CI server). This change explicitly normalizes line endings to CRLF on checkout.

[mousetraps]

I'm not entirely sure why AppVeyor isn't passing with this commit yet, but I actually successfully ran it on the branch itself (before the merge) - notice that ErrorSwitchNoLeftCurly and several other tests pass.
https://ci.appveyor.com/project/mousetraps/nodejstools/build/1.0.157/job/33etaucqbei7ugpx/tests

AppVeyor doesn't clone the working branch directly for PRs, which is likely the reason behind the failed tests.

[mjbvz]

This looks fine, so I've merged it in

According to the docs, I think git always goes with LF for text=auto:

When text is set to "auto", the path is marked for automatic end-of-line normalization. If Git decides that the content is text, its line endings are normalized to LF on checkin.

The issue would only show up after checkin I believe, which would explain why it did not show up in your testing.

[mjbvz]

We may have to now renormalize all the files in the repo too to use crlf.

[mousetraps]

@mjbvz The text attribute enables end-of-line normalization, which means that the line endings are always LF in the repository itself, but they may be represented differently in the working directory.

Originally, we started with * -text, which told git "hey, I know what I'm doing. Don't change anything - l'll handle all the line endings myself." This became problematic because a) our entire repo wasn't all CRLF to begin with, and b) it was too susceptible to text editor differences.

Next, we said

* -text
*.cs text eol=crlf

The problem with this was that a) it was only applicable to *.cs files and b) we hadn't normalized all of the line endings in the repo because of the issue described in #727 (comment)

Next, we changed things up so that a) the line ending normalization would apply more broadly (* text=auto), and b) we would actually normalize all the files this time.
#730

The problem is that I wrongly assumed that * text=auto meant "please normalize my line endings as you best see fit - meaning CRLF in my working directory on Windows, LF in my working directory on *nix". Instead it means "please automatically decide how to apply the text attribute (and thereby normalization to), and if core.eol or core.autocrlf is not set, then use system defaults (CRLF on Windows, LF on *nix)". By some strange stroke of luck, AppVeyor sets core.autocrlf to input (which means "use LF in my working directory", hence the test failures.

Now, we specify * text eol=crlf - which says "apply line ending normalization to all files unless otherwise specified, and always use CRLF in my working directory". That said, I now realize that I should not have removed the =auto, so I'll go ahead and add that back...

Anyways, in conclusion, this is all a really long way of saying... we shouldn't need to renormalize any files. 😃