Add .gitattributes and normalize line endings across repo

[tianon-sso]

• set CRLF as the default checkout encoding for this Windows-native project; text=auto handles binary detection (including UTF-16 LE vendored files) without explicit overrides
• keep *.patch as LF -- vcpkg applies these against LF source trees via git apply
• the remaining 1,753 staged files are a one-time re-normalization of git's internal LF object storage; git diff --ignore-all-space shows only .gitattributes as a real change

Assisted-By: "claude my eyes right out"

(I'm more than happy to rebase, adjust, discuss, amend, etc)

Microsoft Reviewers: Open in CodeFlow

[tianon-sso]

I noticed this while looking at something else -- I'm happy to close instead if that's preferred.

I do not know if my employer (Docker) has signed Microsoft's CLA, but I imagine they have. Is there some way we can check? I can't reasonably sign for them, but this is made in the scope of my work (which is generally all open source and freely licensed).

[tianon-sso]

(one could also argue pretty convincingly that the changes I've made here are pretty categorically un-copywritable, and I'd be perfectly comfortable with that interpretation)

[florelis]

I'm generally okay with this change, but I'd like to have at least one other person in the team weigh in.

I pulled the branch and confirmed there are only whitespace changes besides .gitattributes

I think I'd prefer to have all of the files with the same line endings instead of excluding some types. I would expect all the tooling we use to Just Work® with CRLF.

For the excluded ExternalModules, couldn't we instead do -eol?

For the excluded binary types, I would have expected text=auto to recognize them properly.

[tianon-sso]

❤️

That's all fair and sane, yeah (although -eol isn't a thing - we'd just remove the rule and let text=auto do the right thing naturally); here's a smaller version I'm happy to update to:

# Default: CRLF on checkout - primary tooling is Visual Studio / PowerShell on Windows.
# Git always stores text as LF in the object store; eol= controls the working tree only.
* text=auto eol=crlf

# Patch files must stay LF - git apply and patch(1) match content lines against
# the target source tree, which vcpkg manages as LF internally
*.patch text eol=lf

(should I amend + force-push, or make a new commit for that?)

[tianon-sso]

Aha, I found a case where I've got permission (and we've previously signed a CLA):

@microsoft-github-policy-service agree [company="Docker"]

[tianon-sso]

@microsoft-github-policy-service agree company="Docker"

[Trenly]

The .editorconfig specifies CRLF for all files with very specific exclusions. The new gitattributes file specifies lf endings more broadly. These two should match in their assumptions of which file types use which ending (and should take into account the suggestions from @florelis above)

[Trenly]

(should I amend + force-push, or make a new commit for that?)

Just a new commit should be fine - the PRs here get squash merged, so it's nice to preserve the history on the PR

[tianon-sso]

Totally fair/understood; updated! ❤️

$ git diff --ignore-all-space origin/master..HEAD
diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 00000000..36e0b0c7
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1,7 @@
+# Default: CRLF on checkout - primary tooling is Visual Studio / PowerShell on Windows.
+# Git always stores text as LF in the object store; eol= controls the working tree only.
+* text=auto eol=crlf
+
+# Patch files must stay LF - git apply matches content lines against the target source
+# tree, which vcpkg manages as LF internally
+*.patch text eol=lf
$ git diff --ignore-all-space --stat origin/master..HEAD
 .gitattributes | 7 +++++++
 1 file changed, 7 insertions(+)