Repository navigation
Enable auto EOL on git repo side, fix some character encoding issues - #4912
Conversation
awk -F: '$2 ~ / no line terminators/ {print $1}' ~/text-files.txt | xargs -I{} sh -c 'printf "\n" >> "$1"' - {}
removed file attribute pointing to wrong filename
|
Just to state the obvious, but, the hashes in the tests will need to be updated for the files which were modified. |
0fc3fd6 to
08c4e00
Compare
|
Not sure why the FileCatalog test is failing on AppVeyor. Passing on my WS2016 and WS2012R2 boxes. Figured it out, resaving it locally with just LF EOL I get the same hash as on AppVeyor. So I'm resaving the test file as LF so it should be consistent everywhere. |
08c4e00 to
0a5f9fa
Compare
| GUID = '41486F7D-842F-40F1-ACE4-8405F9C2ED9B' | ||
| Author="Microsoft Corporation" | ||
| CompanyName="Microsoft Corporation" | ||
| Copyright="(c) Microsoft Corporation. All rights reserved." |
There was a problem hiding this comment.
Why we use defferent "c"? I see:
- Copyright (c)
- Copyright (C)
- Copyright ©
There was a problem hiding this comment.
I vaguely recall (c) is completely wrong, (C) has no legal weight, and that © should be used unless the intended process or system cannot parse it (in which case fall back to (C). But I can't find a source.
There was a problem hiding this comment.
IANAL, but doing a search tells me the Berne Convention says none of those symbols are actually needed. Let me follow up with our legal team to see what they recommend so we have consistency. Based on prior experience, I don't expect them to get back to me very quickly, so I suggest we have this as a separate issue #4917
There was a problem hiding this comment.
We can look CoreFX experience.
| @@ -1 +1,3 @@ | |||
| CHANGELOG.md merge=union | |||
| * text=auto | |||
There was a problem hiding this comment.
Based on my reading of the docs, this will only work if the files are not committed CRLF.
When text is set to "auto", the path is marked for automatic end-of-line conversion. If Git decides that the content is text, its line endings are converted to LF on checkin. When the file has been committed with CRLF, no conversion is done.
There was a problem hiding this comment.
From https://www.git-scm.com/docs/gitattributes:
If you want to ensure that text files that any contributor introduces to the repository have their line endings normalized, you can set the text attribute to "auto" for all files.
* text=auto
The actual conversion of files that have CRLF (or worse mixed EOL) will be part of #4910 which we'll do after 6.0.0 final since it touches so many files.
|
Steve Lee (@SteveL-MSFT) Do you want to wait for the copyright issue to be resolved before merging? |
|
Travis Plunk (@TravisEz13) no, I created a separate issue for it #4917 |
|
Steve Lee (@SteveL-MSFT) quick question, I noticed that some |
|
Dongbo Wang (@daxian-dbw) I only changed the ones that were using the Unicode version that doesn't show up in VSCode (easy to search for). I left the ones that use extended ascii. So intentional. |
…owerShell#4912) - add ending newline to files missing it using: `awk -F: '$2 ~ / no line terminators/ {print $1}' ~/text-files.txt | xargs -I{} sh -c 'printf "\n" >> "$1"' - {}` - update .gitattributes to enforce autocrlf on all text files - added <copyright> opening element where it was missing removed file attribute pointing to wrong filename - fix mis-encoded character to apostrophe - replace incorrect encoding of copyright symbol with (c) - updated file hashes in the test
Some of the cleanup work from #4761
cc Michael Klement (@mklement0) Mark Kraus (@markekraus)