Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[windows] bpo-27425: Be more explicit in .gitattributes #840

Merged
merged 3 commits into from Jun 10, 2017
Merged

[windows] bpo-27425: Be more explicit in .gitattributes #840

merged 3 commits into from Jun 10, 2017

Conversation

@zware
Copy link
Member

@zware zware commented Mar 27, 2017

This is largely a direct conversion of .hgeol, assuming I understand the rules of .gitattributes correctly. I also went through and made sure there were actually examples of each entry checked in.

A big difference here is that some of the test files (in test_email, xmltestdata, etc) are no longer marked as binary but rather just -text which should mean that they are not subject to EOL conversion, but git diff provides a nice text diff including line ending changes.

It also expands on .hgeol a bit, with a few more Windows-specific files marked as CRLF.
@mention-bot
Copy link

@mention-bot mention-bot commented Mar 27, 2017

@zware, thanks for your PR! By analyzing the history of the files in this pull request, we identified @vsajip to be a potential reviewer.

serhiy-storchaka
serhiy-storchaka reviewed Mar 27, 2017
View changes
.gitattributes Outdated
Lib/test/coding20731.py -text

# Third party code
Modules/zlib/** -text
Copy link
Member

@serhiy-storchaka serhiy-storchaka Mar 27, 2017

Why the text attribute is unset? Third party code shouldn't be edited, but it can be read as a text.

Copy link
Member Author

@zware zware Mar 27, 2017

To avoid EOL conversion on code that's not ours. There's one file in particular in zlib that caused issues when @doko42 updated our copy of zlib before the GitHub migration; I'm frankly not sure why it's not causing issues currently.

Copy link
Member

@serhiy-storchaka serhiy-storchaka Mar 27, 2017

This is not the only foreign code. libffi, libmpdec, blake2b, Keccak. The only file with non-LF line ending in zlib/ is zlib.map.

.gitattributes Outdated
Modules/zlib/** -text
Modules/expat/** -text

# CRLF files
Copy link
Member

@serhiy-storchaka serhiy-storchaka Mar 27, 2017

Shouldn't the text attribute be set if use the eol attribute?

Copy link
Contributor

@AraHaan AraHaan Mar 27, 2017 •
edited

tbh even if I use Windows I still perfer LF over CRLF for endlines. Although I use Notepad++, I would have liked if Windows notepad was to show files with LF line endings just like it would with files with CRLF. However it does not in Windows 7 all the way up to Windows 10 and it annoys me forcing me to use Notepad++ to begin with although with Notepad++ I also get syntax highlighting that Windows Notepad also does not have. Although even then I like LF more because it can safe a little bit more space than CRLF(\r\n) would.

Be nice if there was an Windows update for Windows 7 and newer that would patch Windows Notepad to allow proper and easily read files with LF as if it was in CRLF.

Anyways @zooba mind forwarding my Windows Notepad issues to the proper team to patch it on Windows 7 SP1 and newer for me please?

Copy link
Member Author

@zware zware Mar 27, 2017

@serhiy-storchaka According to the gitattributes docs:

eol
This attribute sets a specific line-ending style to be used in the working directory. It enables end-of-line conversion without any content checks, effectively setting the text attribute.

@AraHaan This is not the place to discuss well-known issues with Notepad. It is also not the place to ask personal favors of anybody.

Copy link
Member

@serhiy-storchaka serhiy-storchaka Mar 27, 2017

All examples in the gitattributes docs use eol only together with text.

Lib/venv/scripts/nt/activate.bat Outdated
set "PATH=%VIRTUAL_ENV%\__VENV_BIN_NAME__;%PATH%"

:END
echo test
Copy link
Member

@serhiy-storchaka serhiy-storchaka Mar 27, 2017

Is this the debugging artifact?

Copy link
Member Author

@zware zware Mar 27, 2017

Apparently so, good catch!

.gitattributes

# Text files that should not be subject to eol conversion
Lib/test/cjkencodings/* -text
Lib/test/decimaltestdata/*.decTest -text
Copy link
Member

@serhiy-storchaka serhiy-storchaka Mar 27, 2017

They are text files.

Copy link
Member Author

@zware zware Mar 27, 2017

As best I can tell, -text in .gitattributes just means "don't change the end-of-line character used in this file regardless of settings like core.autocrlf or core.eol". Editing the file and running git diff still results in a readable diff (preventing that is controlled by -diff, which is included in the binary macro).

Copy link
Member

@serhiy-storchaka serhiy-storchaka Mar 27, 2017 •
edited

*.decTest files are read in test_decimal.py as text files. No need to prevent changing the end-of-line character.

Copy link
Member Author

@zware zware Mar 27, 2017

But they are imported from elsewhere, and it would be good to keep them the same as they were imported. @skrah may have an opinion on this.

Copy link
Contributor

@skrah skrah Mar 27, 2017

Most of them are imported from http://speleotrove.com/decimal/dectest.html (dectest.zip).

I agree with Zachary.

Copy link
Member

@serhiy-storchaka serhiy-storchaka Mar 27, 2017

Should they be converted to CRLF line ending as in decTest.zip?

Copy link
Contributor

@skrah skrah Mar 27, 2017 •
edited

Which ones? I just opened Lib/test/decimaltestdata/ddInvert.decTest and it's DOS as expected.

Copy link
Member

@serhiy-storchaka serhiy-storchaka Mar 27, 2017

I just opened the first file abs.decTest and it has LF line ending.

Copy link
Contributor

@skrah skrah Mar 27, 2017

Okay, then it would be reasonable to convert all files that are also in decTest.zip to CRLF.

Copy link
Contributor

@skrah skrah Mar 27, 2017

Conversion of course not necessarily as part of this issue, unless someone has the patience to do that. ;)

@vstinner vstinner mentioned this pull request Mar 27, 2017
Merged
@vstinner vstinner changed the title bpo-27425: Be more explicit in .gitattributes [windows] bpo-27425: Be more explicit in .gitattributes Mar 27, 2017
serhiy-storchaka
serhiy-storchaka approved these changes Apr 2, 2017
View changes
Copy link
Member

@serhiy-storchaka serhiy-storchaka left a comment

LGTM, but I would prefer to add explicit text if eof= is used (official .gitattributes examples add it). And either remove zlib and expat or add other third party code directories.

zware added 2 commits Jun 4, 2017
@zware
Be more explicit in .gitattributes
d699c78
@zware
Use 'text' tag with 'eol=', don't bother with third-party stuff
74f2885
@zware zware force-pushed the update_gitattributes branch from 7841d57 to c74bc40 Jun 4, 2017
@zware
Commit line ending fixes
1e61282
@zware zware force-pushed the update_gitattributes branch from c74bc40 to 1e61282 Jun 4, 2017
@zware zware merged commit 6b6e687 into python:master Jun 10, 2017
3 checks passed
@zware zware deleted the update_gitattributes branch Jun 10, 2017
@zware zware mentioned this pull request Jun 10, 2017
Merged
@zware zware mentioned this pull request Jun 10, 2017
Merged
@zware zware mentioned this pull request Jun 10, 2017
Merged
zware added a commit that referenced this issue Jun 10, 2017
@zware
[3.6] bpo-27425: Be more explicit in .gitattributes (GH-840) (GH-2083)
964c261 
Also updates checked-in line endings on some files
zware added a commit that referenced this issue Jun 10, 2017
@zware
[3.5] bpo-27425: Be more explicit in .gitattributes (GH-840) (GH-2084)
afa6a38 
Also updates checked-in line endings on some files.
zware added a commit to zware/cpython that referenced this issue Jun 11, 2017
@zware
Fix more line endings (pythonGH-840)
60cda64
zware added a commit to zware/cpython that referenced this issue Jun 11, 2017
@zware
Fix more line endings (pythonGH-840)
c38c591
zware added a commit to zware/cpython that referenced this issue Jun 11, 2017
@zware
Fix more line endings (pythonGH-840)
e657b76
zware added a commit that referenced this issue Jun 11, 2017
@zware
Show what's changed when Travis fails regen check (GH-2095)
3f8f16d 
Also fixed a few more line endings that were missed in GH-840, which were causing failure.
zware added a commit that referenced this issue Jun 11, 2017
@zware
[3.6] Use Travis to make sure all generated files are up to date (GH-…
f57e34b 
…2080) (GH-2092)

(cherry picked from commit 0afbabe)

Also fixes some line endings missed in GH-840 backport.
zware added a commit that referenced this issue Jun 11, 2017
@zware
[3.5] Use Travis to make sure all generated files are up to date (GH-…
80bdbf6 
…2080) (GH-2093)

(cherry picked from commit 0afbabe)

Also fixes some line endings missed in GH-840 backport.
zware added a commit that referenced this issue Jun 11, 2017
@zware
[2.7] bpo-27425: Be more explicit in .gitattributes (GH-840) (GH-2086)
5fe8ac6 
Also updates checked-in line endings in several files.
mlouielu added a commit to mlouielu/cpython that referenced this issue Jun 15, 2017
@zware @mlouielu
bpo-27425: Be more explicit in .gitattributes (pythonGH-840)
5d22386 
Updates checked-in line endings on several files.
mlouielu added a commit to mlouielu/cpython that referenced this issue Jun 15, 2017
@zware @mlouielu
Show what's changed when Travis fails regen check (pythonGH-2095)
9c892b9 
Also fixed a few more line endings that were missed in pythonGH-840, which were causing failure.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@AraHaan AraHaan

@skrah skrah

@berkerpeksag berkerpeksag

@serhiy-storchaka serhiy-storchaka

Assignees
No one assigned
Labels
CLA signed OS-windows
Projects
None yet
Milestone
No milestone
9 participants
@zware @mention-bot @berkerpeksag @serhiy-storchaka @AraHaan @skrah @vstinner @Mariatta @the-knights-who-say-ni