Normalize line endings to LF via .gitattributes - #50
Conversation
Line-ending policy was previously implicit in each contributor's
core.autocrlf, so the repository drifted into a mix: 23 .jl files stored
CRLF vs 20 LF, 3 .md vs 19, and even the two CI workflow files split one
each way. That asymmetry is a live trap -- editing a CRLF-stored file on a
machine with core.autocrlf=true rewrites the whole file to LF on commit,
burying a one-line change in whole-file churn (the earlier "Restore CRLF
line endings on types.jl, DatabentoBinaryEncoding.jl, runtests.jl" commit
was cleaning up exactly this).
`* text=auto` makes LF the canonical stored form for all detected text,
independent of any local git config. Working trees may still use CRLF.
Also fixes a latent bug: benchmark/verify_setup.sh was stored with CRLF,
which fails under bash ("bad interpreter: /bin/bash^M"). It is now LF.
The 81 binary fixtures under test/data/ are marked `binary` explicitly.
They were already safe by git's NUL-byte heuristic, but these files are
byte-compared by the round-trip tests, so the exemption should not depend
on content sniffing -- a future fragment without an early NUL would
otherwise be silently CRLF-mangled.
Verified mechanically: every file in this commit is byte-identical to its
previous content once CR characters are removed, and no file under
test/data/ is touched.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Keeps `git blame` pointing at real authorship rather than the whole-file renormalization commit. GitHub applies this file automatically; locally it needs `git config blame.ignoreRevsFile .git-blame-ignore-revs`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 46c6b399eb
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| # git config blame.ignoreRevsFile .git-blame-ignore-revs | ||
|
|
||
| # Normalize line endings to LF via .gitattributes (no content changes) | ||
| 659fb36bec08d6bde072efe982ddc63303ba6103 |
There was a problem hiding this comment.
When this proposed commit is merged, the normalization revision will be f977d787…, but this entry names the sibling commit 659fb36…, which is not an ancestor of it. Consequently, git blame --ignore-revs-file .git-blame-ignore-revs f977d787 -- src/types.jl still attributes the normalized lines to f977d787, defeating the stated purpose of the file; record this commit's actual hash instead.
Useful? React with 👍 / 👎.
1 participant
Why
Line-ending policy was implicit in each contributor's
core.autocrlf, so the repo drifted into a mix — 23.jlfiles stored CRLF vs 20 LF, 3.mdvs 19, and even the two CI workflow files split one each way.That asymmetry is a live trap: editing a CRLF-stored file on a machine with
core.autocrlf=truerewrites the whole file to LF on commit, burying a one-line change in whole-file churn. The earlier "Restore CRLF line endings on types.jl, DatabentoBinaryEncoding.jl, runtests.jl" commit was cleaning up exactly this, and it recurred while preparing the v0.1.7 release (a 1-lineruntests.jlchange came out as 93 lines).What
.gitattributeswith* text=auto— LF becomes the canonical stored form for all detected text, independent of any local git config. Working trees may still use CRLF on Windows.*.dbn,*.dbz,*.zst,*.frag→binary). All 81 files undertest/data/were already safe via git's NUL-byte heuristic, but they're byte-compared by the round-trip tests, so the exemption shouldn't depend on content sniffing — a future fragment without an early NUL would otherwise be silently CRLF-mangled..git-blame-ignore-revsso the renormalization commit doesn't pollutegit blame.Also fixes a latent bug
benchmark/verify_setup.shwas stored with CRLF, which fails under bash (bad interpreter: /bin/bash^M). Nothing in CI runs it, so it went unnoticed. Now LF.Verification
Mechanically checked that every file in the normalization commit is byte-identical to its previous content once CR characters are removed, and that no file under
test/data/is touched.Same counts as before the change.
Timing
Opened while there are no other PRs in flight and immediately after the v0.1.7 release, so the churn commit can't conflict with anything and sits at a clean version boundary.
🤖 Generated with Claude Code