style: restore CRLF line endings in the nn and qlearn suites - #179
Merged
Merged
Conversation
#178 converted unit_test/nn/nn_unit_test.cpp and unit_test/qlearn/qlearn_unit_test.cpp from CRLF to LF as a side effect of being edited through Python's text mode, which normalizes newlines on write. Both files have been CRLF for their whole history. The content change in that PR was 33 added and 8 removed lines in nn, and 7 added and 10 removed in qlearn. The recorded diff was 17011 and 1959 lines, because every line in both files counted as rewritten. That buries the real change, makes the PR unreviewable, and poisons git blame for two of the largest files in the tree. Converts both back. No content change: the suites build and pass unchanged. kan_unit_test.cpp was already LF and is untouched.
danmcleran
added a commit
that referenced
this pull request
Aug 31, 2026
Editing a CRLF file with a tool that normalizes newlines rewrites the whole file. In #178 a +33/-8 change to nn_unit_test.cpp was recorded as 17,011 lines, which buried the real change and poisoned git blame; #179 undid it by hand. Nothing in CI catches this -- line endings do not affect compilation, so every gate stays green while the diff is unreviewable. This makes the mistake structurally impossible rather than a matter of who edits next. `* text=auto` has git store LF in the repository, and the files that are CRLF in the working tree -- the original core headers, the first examples, the two oldest test suites, the UML sources and one dataset -- are pinned with `text eol=crlf` so checkout still gives them CRLF. Everything added since is LF and needs no entry. The effect is that a tool which converts endings now produces no diff at all: the index holds LF either way, and checkout restores the working-tree convention. Verified by repeating the #178 mistake against these rules -- the same operation that produced +8518/-8518 now produces nothing, and checkout restores CRLF. This commit therefore renormalizes what the repository stores for those files. That is a one-time whole-file diff for each, and the last one they will have for this reason. Checked two ways first: every staged change is line-endings only (content compared with CR stripped), and no file's working-tree endings change.
danmcleran
added a commit
that referenced
this pull request
Aug 31, 2026
Editing a CRLF file with a tool that normalizes newlines rewrites the whole file. In #178 a +33/-8 change to nn_unit_test.cpp was recorded as 17,011 lines, which buried the real change and poisoned git blame; #179 undid it by hand. Nothing in CI catches this -- line endings do not affect compilation, so every gate stays green while the diff is unreviewable. This makes the mistake structurally impossible rather than a matter of who edits next. `* text=auto` has git store LF in the repository, and the files that are CRLF in the working tree -- the original core headers, the first examples, the two oldest test suites, the UML sources and one dataset -- are pinned with `text eol=crlf` so checkout still gives them CRLF. Everything added since is LF and needs no entry. The effect is that a tool which converts endings now produces no diff at all: the index holds LF either way, and checkout restores the working-tree convention. Verified by repeating the #178 mistake against these rules -- the same operation that produced +8518/-8518 now produces nothing, and checkout restores CRLF. This commit therefore renormalizes what the repository stores for those files. That is a one-time whole-file diff for each, and the last one they will have for this reason. Checked two ways first: every staged change is line-endings only (content compared with CR stripped), and no file's working-tree endings change.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes an unintended side effect of #178. My error, not a pre-existing issue.
What happened
unit_test/nn/nn_unit_test.cppandunit_test/qlearn/qlearn_unit_test.cpphave been CRLF for their whole history. I edited them through Python's text mode, which normalizes newlines on write, silently converting both to LF.Why it matters
The actual content change in #178 was small:
nn_unit_test.cppqlearn_unit_test.cppEvery line counted as rewritten. That buries the real change, makes the PR unreviewable, and poisons
git blamefor two of the largest files in the tree.This PR
Converts both back to CRLF. No content change —
nnandqlearnbuild and pass unchanged.kan_unit_test.cppwas already LF and is untouched.🤖 Generated with Claude Code
https://claude.ai/code/session_019tVgXeXCcfbHqfMjhufWzd