Remove eol attribute for cs files

[mjbvz]

I added the text attribute after bulk converting all *.cs files to crlf line endings, thinking that it would force edits to also use crlf going foward. Instead, it's causing a ton of trouble for me and introducing lots of fake edits.

Here's the problem:

• On a clean branch, use VS to edit a file.
• Verify that the file has crlf line endings before editing it.
• Save the file.
• File still has crlf line endings.
• git now shows the entire file has been changed.

Removing the text attribute gets us back to where we started and fixed the problem for me.

[msftclas]

Hi @mjbvz, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Matt Bierner). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

[mjbvz]

I've tried but I can't undo this change. It's whitespace only but git refuses to see that anything has been changed even after checking out this file directly from this repo directly.

[mousetraps]

Closing in favor of #730.

BTW from what I can tell, the issue was that git got stuck in this very odd state - with the eol=crlf flag set, the files should be represented as LF in the repo. But there was a set of files that were both CRLF locally and in the repo. So once you touched some files, locally it didn't really look any different, but the diff was reporting back that the entire file had changed because it was about to do an invisible-to-the-user conversion from CRLF to LF.

I suspect your other PR #709 didn't catch this because git rm --cached -r . && git reset --hard didn't attempt to convert the line endings of files that were already being checked out as CRLF. In this case, ended up getting past it by touching all the files and then committing the result of that.