Repository navigation
Checkouts stale following changes to .gitattributes #88942
Description
| BPO | 44779 |
|---|---|
| Nosy | @jaraco, @jkloth, @eamanu |
| PRs |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2021-07-30.14:21:05.787>
labels = ['docs']
title = 'Checkouts stale following changes to .gitattributes'
updated_at = <Date 2021-07-31.13:27:52.992>
user = 'https://github.com/jaraco'bugs.python.org fields:
activity = <Date 2021-07-31.13:27:52.992>
actor = 'eamanu'
assignee = 'docs@python'
closed = False
closed_date = None
closer = None
components = ['Documentation']
creation = <Date 2021-07-30.14:21:05.787>
creator = 'jaraco'
dependencies = []
files = []
hgrepos = []
issue_num = 44779
keywords = ['patch']
message_count = 1.0
messages = ['398552']
nosy_count = 4.0
nosy_names = ['jaraco', 'jkloth', 'docs@python', 'eamanu']
pr_nums = ['27436']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue44779'
versions = []
Activity
jaraco commented on Jul 30, 2021
In this comment, I learned that it's possible to get repo clones into a bad state by:
Users (including buildbots) that pulled the code between these two steps will be stuck with the files at the state checked out in the first step.
Example (must be run on Windows):
PS C:\> git clone https://github.com/python/cpython --depth 100
Cloning into 'cpython'...
remote: Enumerating objects: 5946, done.
remote: Counting objects: 100% (5946/5946), done.
remote: Compressing objects: 100% (5079/5079), done.
Receiving objects: 100% (5946/5946), 24.99 MiB | 9.18 MiB/s, done.
remote: Total 5946 (delta 1382), reused 2314 (delta 758), pack-reused 0
Resolving deltas: 100% (1382/1382), done.
Updating files: 100% (4699/4699), done.
PS C:\> cd cpython
PS C:\cpython> git checkout aaa83cd^1
HEAD is now at 851cca8 Add missing gdbm dependencies to the UNIX CI (GH-27467)
PS C:\cpython> # simulate as if this rev was the the initial checkout
PS C:\cpython> git rm -r :/ > $null ; git checkout HEAD -- :/
PS C:\cpython> python -c "import pathlib; print(repr(pathlib.Path('Lib/test/test_importlib/namespacedata01/utf-8.file').read_bytes()))"
b'Hello, UTF-8 world!\r\n'
PS C:\cpython> git checkout -q aaa83cd
HEAD is now at aaa83cd bpo-44771: Apply changes from importlib_resources 5.2.1 (GH-27436)
PS C:\cpython> python -c "import pathlib; print(repr(pathlib.Path('Lib/test/test_importlib/namespacedata01/utf-8.file').read_bytes()))"
b'Hello, UTF-8 world!\r\n'
PS C:\cpython> git rm -r :/ > $null ; git checkout HEAD -- :/
PS C:\cpython> python -c "import pathlib; print(repr(pathlib.Path('Lib/test/test_importlib/namespacedata01/utf-8.file').read_bytes()))"
b'Hello, UTF-8 world!\n'
This issue doesn't exist on other repos (the file has Unix newlines in all checkouts):
PS C:\> git clone https://github.com/python/importlib_resources
Cloning into 'importlib_resources'...
remote: Enumerating objects: 2811, done.
remote: Counting objects: 100% (732/732), done.
remote: Compressing objects: 100% (400/400), done. eceiving objects: 1% (29/2811)
remote: Total 2811 (delta 456), reused 556 (delta 309), pack-reused 2079
Receiving objects: 100% (2811/2811), 446.21 KiB | 7.44 MiB/s, done.
Resolving deltas: 100% (1796/1796), done.
PS C:\> cd importlib_resources
PS C:\importlib_resources> python -c "import pathlib; print(repr(pathlib.Path('importlib_resources/tests/namespacedata01/utf-8.file').read_bytes()))"
b'Hello, UTF-8 world!\n'
I'm not sure there's much this project can do, except maybe consider minimizing the number of files that need customization.
As a former Windows enthusiast, I found the CRLF changes to be annoying an not particularly useful, so I sought to use LF for newlines wherever possible, for simplicity and consistency. Some editors (notably Notepad) would not handle these newlines well, but almost all other editors would handle them just fine.
This project could consider standardizing on Unix newlines with a small number of exceptions rather than allowing files by default to be converted to platform-specific newlines.
I'm yet unsure what setting it is about the CPython repo that causes newlines to be customized per platform but importlib_resources does not.