fix(docs/.gitattributes): comment accuracy on EOL policy#353
Merged
Chris-Wolfgang merged 1 commit intoMay 10, 2026
Merged
Conversation
Two doc/comment inaccuracies caught by Copilot review on Try-Pattern PR #110 (the comprehensive sync from canonical): 1. docs/README-FORMATTING.md: the example said .gitattributes 'forces CRLF on *.ps1' which is the OPPOSITE of the current policy (PR #347/#348 established LF for *.ps1 with explicit eol=lf). Reworded to say all text files are LF, with a brief note that *.ps1 historically used CRLF before the switch. 2. .gitattributes: the *.ps1 comment said 'Git's autocrlf still gives Windows users CRLF in their working tree if desired without forcing CRLF into the index'. This is wrong — the explicit 'eol=lf' on the following line overrides core.autocrlf entirely; users get LF in both the index AND the working tree regardless of autocrlf setting. Reworded to state that explicitly. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Updates documentation and inline comments to accurately reflect the repository’s current line-ending policy (LF for all text files, including *.ps1) and clarifies how .gitattributes interacts with core.autocrlf.
Changes:
- Corrected
docs/README-FORMATTING.mdto state that.gitattributesenforces LF for all text files (including PowerShell scripts), and noted the historical CRLF policy for*.ps1. - Reworded the
*.ps1comment in.gitattributesto accurately state thateol=lfoverridescore.autocrlfon checkout (LF in working tree as well as normalized LF in the index).
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
docs/README-FORMATTING.md |
Fixes formatting documentation to match the repo’s LF-only EOL policy (including *.ps1). |
.gitattributes |
Clarifies the *.ps1 EOL behavior and the precedence over core.autocrlf. |
Chris-Wolfgang
deleted the
fix/readme-formatting-and-gitattributes-comment-accuracy
branch
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
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.
Summary
Two doc/comment inaccuracies caught by Copilot review on Try-Pattern PR #110 (comprehensive sync from canonical).
Changes
docs/README-FORMATTING.mdThe example said
.gitattributes"forces CRLF on*.ps1" — but the current policy (established in #347/#348) is the opposite:*.ps1 text eol=lf. Reworded to say all text files are LF, with a brief note that*.ps1historically used CRLF before the switch..gitattributesThe
*.ps1comment said:This is wrong — the explicit
eol=lfon the following line overridescore.autocrlfentirely. Users get LF in both the index AND the working tree regardless of theirautocrlfsetting. Reworded to state that explicitly.Note about the protected-files guard
This PR touches
.gitattributes(a protected file). TheDetect .NET Projectsguard will block — maintainer override required.Cascade
After this lands, future downstream sync PRs pulling these files won't reintroduce the misleading text.