[yebuguntang]

Purpose of the pull request

Closes #1264

mvnw.cmd always shows as modified in git status after cloning, even though nobody changed the file. .gitattributes says *.cmd blobs are stored as LF, but this one was committed with CRLF before the rule existed (#1049).

What's changed?

git add --renormalize mvnw.cmd

The stored blob becomes LF. The file Windows users check out is unchanged, same hash before and after. Verified:

• git ls-files --eol now reports i/lf w/crlf
• staged diff with --ignore-cr-at-eol comes back empty
• git status is clean after the commit
• mvnw.cmd -DskipTests package still builds

No docs or test changes needed — this only touches how the file is stored in git, not its content.

Checklist

• I have read the Contributor Guide.
• I have written the necessary doc or comment.
• I have added the necessary unit tests and all cases have passed.

[yebuguntang]

Hi @GOODBOY008 , could you review this small fix? It resolves #1264 — mvnw.cmd always shows as modified after cloning on Windows. Verified the stored blob becomes LF while the checked-out file is unchanged. Thanks!

[Mikkey-f]

Verified on Windows 11:

• On current main: git ls-files --eol mvnw.cmd → i/crlf w/crlf attr/text eol=crlf, and a fresh worktree reports M mvnw.cmd — reproduces #1264.
• On this PR: i/lf w/crlf attr/text eol=crlf, and git status --porcelain is clean.
• git diff --ignore-cr-at-eol origin/main...HEAD is empty, so only the stored line endings change; the checked-out script stays CRLF for cmd.exe.

LGTM — this fixes the fresh-clone symptom, and existing clones pick it up on pull.