[Task] mvnw.cmd always shows as modified after cloning
Maintainer thường phản hồi trong vòng 1 ngày
Đánh giá
- Độ khó
- 1/5
- Thời gian dự kiến
- Dưới một giờ
- Mức phù hợp với người mới
- 91/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- git, github, java
- Lĩnh vực
- build-system
Hướng nghiên cứu
Bắt đầu từ quy tắc .gitattributes được đề cập trong issue và kiểm tra kiểu xuống dòng của tệp được theo dõi bằng git ls-files --eol mvnw.cmd. Trên một nhánh tách từ main, chạy git add --renormalize mvnw.cmd; xác nhận diff đã stage trống với --ignore-cr-at-eol, index báo i/lf và working tree báo w/crlf, đồng thời hash của tệp làm việc không đổi sau khi checkout lại.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Motivation
mvnw.cmd always shows as modified in git status after cloning — 188 insertions, 188 deletions, all line-ending noise — but clicking the diff shows no actual content change.
.gitattributes tells git to store *.cmd as LF and convert to CRLF on checkout, but the committed blob for this file already contains CRLF, so the comparison never matches:
The rule was added in #1049 (c614183) without renormalizing the file. It's the only tracked file with this problem, out of 930. Reproduces on a fresh clone; core.autocrlf makes no difference (same with true, input, false).
Nothing breaks because of it, but anyone running git commit -a will commit a whitespace-only change without noticing.
How to complete
git add --renormalize mvnw.cmd
on a branch off main. The stored blob becomes LF; the file Windows users get on checkout is unchanged, same hash before and after re-checkout.
Task List
- renormalize
mvnw.cmd -
git ls-files --eolreportsi/lf w/crlf - staged diff with --ignore-cr-at-eol comes back empty
- working file hash unchanged after re-checkout
- PR: chore: renormalize mvnw.cmd line endings
Anything else?
No response
- Ngôn ngữ chính
- Java
- Star
- 6.3k
- Fork
- 545
- Merge trung bình
- 2 ngày 22 giờ
- Pull request đã merge (30 ngày)
- 41
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của apache/fesod
-
[Enhancement] Allow static imports in test sources so AssertJ is usableCó thể đã có người làm @qiaolezi001 đã nhận 1 ngày trước. Đang mởenhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 69/100
apache/fesod#1267 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
discussion welcome security waiting for feedback
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
apache/fesod#1184 · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug] xlsx stream write leaves temp fileCó thể đã có người làm @nkuprins đã nhận 23 ngày trước. Đang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
apache/fesod#1137 · 1 bình luận · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug] A cell read into a ReadCellData field loses its row and column indexCó thể đã có người làm @CodeMan-cmd đã nhận 37 ngày trước. Đang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
apache/fesod#1131 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[bug]Custom converters with supportExcelTypeKey() == null are silently ignored when writing CSVCó thể đã có người làm @Mikkey-f đã nhận 53 ngày trước. Đang mở
Độ khó 2/5 Nửa ngày Mức phù hợp với người mới 84/100
Maintainer thường phản hồi trong vòng 1 ngày
Issue tương tự
-
bug/错误
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 64/100
FCL-Team/FoldCraftLauncher#1982 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[BUG] micronaut-serde-oracle-jdbc-json brings a second OJDBC driver onto the runtime classpathCó thể đã có người làm @ZARAYACH đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
micronaut-projects/micronaut-serialization#1494 · 4 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 73/100
Maintainer thường phản hồi trong vòng 2 ngày
-
bug
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 85/100
vitruv-tools/Vitruv-Change#600 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
code-health feature/sync OS/Android QA/Test-Plan-Specified QA/Yes
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
brave/brave-browser#60327 ·
Maintainer thường phản hồi trong vòng 1 ngày