jamesfredley opened a new pull request, #15709: URL: https://github.com/apache/grails-core/pull/15709
## Companion to #15708 [#15708](https://github.com/apache/grails-core/pull/15708) renormalizes the **11** CR-containing files shared across `7.0.x` / `7.1.x` / `7.2.x` / `8.0.x` and will merge-forward up the chain. I verified `7.1.x` and `7.2.x` carry the identical 11-file set (no extras), so they are fully covered by that merge-forward. `8.0.x` carries **4 additional** Gradle wrapper batch scripts stored with CRLF blobs that are already LF on the 7.x line - so the merge-forward will **not** fix them: - `build-logic/gradlew.bat` - `grails-gradle/gradlew.bat` - `grails-profiles/profile/skeleton/gradlew.bat` - `grails-shell-cli/src/test/resources/gradle-sample/gradlew.bat` ## Why they go "permanently dirty" (Full root-cause writeup in #15708.) `.gitattributes` declares `*.bat text eol=crlf`, so the committed/index form must be **LF** while the working tree is checked out as **CRLF**. A CRLF-stored blob permanently conflicts: git normalizes the working copy to LF and compares it against the CRLF blob, which never matches. The file flips to modified the moment any tool (IDE Gradle sync, branch switch, build, editor save) busts git's lstat cache, and `git checkout` / `git reset` cannot repair it because the wrong bytes live in the committed blob. ## Fix `git add --renormalize` on exactly those 4 files. Pure line-ending change: `git diff --ignore-cr-at-eol` is empty (328 insertions / 328 deletions, every line re-emitted with CR stripped). Working trees are unaffected - `eol=crlf` keeps the scripts CRLF on checkout, so **Windows behavior does not change**. ## Conflict-free by construction This PR's file set is **disjoint** from #15708's, so the two cannot conflict during merge-forward in either order. Once both land, all 15 CR-containing files on `8.0.x` are normalized. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
