align files to .editorconfig

[tg123]

eclint fix **/*.cs

check will integrate with CI process

#37

@gitfool

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: tg123
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: brendandburns

If they are not already assigned, you can assign the PR to them by writing /assign @brendandburns in a comment when ready.

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[gitfool]

@tg123 I didn't know about eclint. Nice!

I see all the line endings are still CRLF though, despite the .editorconfig specifying LF. When editing an existing file it seems the existing EOL is preserved. However, when creating a new file (in VS 2017 at least) it will use LF, so either .editorconfig should be changed to specify CRLF or the EOL should be changed to LF for all existing files.

[tg123]

@gitfool
only eclint with *.cs
and generated codes are ignored

[gitfool]

I ran the same command as you on your branch, eclint fix **/*.cs, and all cs files were further updated, as expected, to use LF for EOL. So you must've passed CRLF on the command-line to eclint; but this has the problem I mention above.

[tg123]

@gitfool I checked all .cs are LF except /src/KubernetesClient/generated/
for generated they should be handled by autorest.

my command

find . -name *.cs -exec file {} \; | grep CRLF | grep -v generated

[gitfool]

Right. If I clone your repo in WSL then I get LF. If I clone in Windows then I get CRLF. The problem is that because there's no .gitattributes file, it depends on everyone's git client settings. If I edit an existing file on Windows it will be committed using CRLF.

The other approach is to remove the end_of_line entry from .editorconfig and add a .gitattributes file. See dealing-with-line-endings and the gitattributes repo for some relevant templates. If specified correctly then text files will match the os platform when editing but always be stored in git using LF.

[tg123]

@gitfool you may be a victim of autocrlf

[gitfool]

Haha. I've been the victim of many EOL abuses. The point is everyone has their own settings and you can't expect them to comply with your settings, so the best way to address this is with a .gitattributes file in the repo. This and .gitignore should be the first files added to a new repo. When added late you have to renormalize line endings which can make a mess of the repo history.

[tg123]

@gitfool after fully eclint (or some other solution) integrated.
bad line ending will be blocked from merging to master see #37

[gitfool]

That's all very well, and is one way to lock things down, but again you've missed the point. You're only considering what you use. A .gitattributes file is particularly important for cross-platform projects where developers will use different tools on different operating systems. I give up.

[tg123]

@gitfool thanks I see, that is a good idea.
You can create a PR for that

[gitfool]

Cool. Will do after this is PR merged, since they'll overlap.

[brendandburns]

LGTM.