fix: renormalize gradlew.bat so a fresh clone is clean - #33
Conversation
`.gitattributes` declares `gradlew.bat text eol=crlf`, so git expects the blob
stored in the repository to be LF and the working-tree copy to be CRLF. The
committed blob is CRLF instead — it predates the attribute — so on every clone
git checks the file out as-is, re-hashes it through the clean filter to LF, and
reports it modified.
The result is that `git status` is dirty the instant you clone, before touching
anything:
$ git clone … && cd kzstd && git status --porcelain
M gradlew.bat
Verified this is not a local configuration problem: fresh clones with
core.autocrlf=false and core.autocrlf=input are both affected, because a path
attribute overrides autocrlf either way. `git ls-files --eol` names the cause
directly — `i/crlf w/crlf attr/text` where an LF index blob is expected.
`git add --renormalize` fixes it: the blob becomes LF, the checkout stays CRLF
as the attribute intends, and the tree is clean and stays clean across
subsequent checkouts. The diff is 82 lines each way and entirely line endings;
`git diff --ignore-cr-at-eol` is empty.
Beyond the papercut, a permanently-dirty tracked file suppresses real tooling:
anything that declines to act on a dirty tree — release scripts, bisect, and in
our case a workspace sync that skips repos with modified tracked files — skips
this repo forever.
Signed-off-by: James Rich <james.a.rich@gmail.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe Windows Gradle wrapper script was converted to normalized line endings. Its startup, Java discovery, error handling, execution, and exit-status propagation remain unchanged. ChangesGradle wrapper normalization
Estimated code review effort: 1 (Trivial) | ~3 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The problem
git statusis dirty the instant you clone, before touching anything:.gitattributesdeclaresgradlew.bat text eol=crlf, so git expects the blob stored in the repository to be LF and the working-tree copy to be CRLF. The committed blob is CRLF instead — it predates the attribute. So git checks the file out as-is, re-hashes it through the clean filter to LF, and reports a modification that can never be resolved by editing.git ls-files --eolnames it directly:Not a local configuration problem. I checked fresh clones under both
core.autocrlf=falseandcore.autocrlf=input; both are affected, because a path attribute overridesautocrlfeither way. Every clone of this repo has this.The fix
git add --renormalize gradlew.bat. The blob becomes LF, the checkout stays CRLF as the attribute intends:The diff is 82 lines each way and is entirely line endings —
git diff --ignore-cr-at-eolis empty. Windows users are unaffected: the working-tree copy is still CRLF, which is whateol=crlfguarantees and whatcmd.exeneeds.Verification
Cloned the branch fresh:
git status --porcelainis empty, and stays empty after deleting and re-checking-out the file.Why it's worth fixing
Beyond the papercut, a permanently-dirty tracked file silently suppresses tooling that declines to act on a dirty tree — release scripts,
git bisect, and in my case a multi-repo sync that skips repos with modified tracked files, so it skipped this one indefinitely.🤖 Generated with Claude Code
Summary by CodeRabbit