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
SteveL-MSFT
requested review from
BrucePay,
JamesWTruher,
PaulHigin,
dantraMSFT,
lzybkr,
mirichmo and
vors
as code owners
|
Just to state the obvious, but, the hashes in the tests will need to be updated for the files which were modified. |
SteveL-MSFT
force-pushed
the
file-cleanup
branch
3 times, most recently
from
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. |
SteveL-MSFT
force-pushed
the
file-cleanup
branch
from
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.
|
@SteveL-MSFT Do you want to wait for the copyright issue to be resolved before merging? |
|
@TravisEz13 no, I created a separate issue for it #4917 |
|
@SteveL-MSFT quick question, I noticed that some |
|
@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. |
6 participants
Some of the cleanup work from #4761
cc @mklement0 @markekraus