[PATCH] D124563: Renormalize line endings after ac5f7be6a8688955a282becf00eebc542238a86b

Di Mo via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Apr 27 16:52:25 PDT 2022

modimo added a comment.

In D124563#3478561 <https://reviews.llvm.org/D124563#3478561>, @smeenai wrote:

> The following files have their line endings (when checked out on disk) changed from CRLF to LF by this patch. Seems harmless, but I just wanted to confirm that it was expected:
>   clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-duplicate-include/readability-duplicate-include.h
>   clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-duplicate-include/readability-duplicate-include2.h
>   clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-duplicate-include/system/sys/types.h
>   clang-tools-extra/test/clang-tidy/checkers/readability-else-after-return-if-constexpr.cpp
>   clang-tools-extra/test/modularize/Inputs/CompileError/module.modulemap
>   clang-tools-extra/test/modularize/Inputs/MissingHeader/module.modulemap
>   clang-tools-extra/test/pp-trace/Inputs/module.map
> (The files which should be CRLF according to `.gitattributes` remained CRLF.)

Good catch. Looking at git documentation (https://git-scm.com/docs/gitattributes#_text) by virtue of applying `* text=auto` the line endings will be stored internally as LF and then use the system settings on checkout. Looking on my linux box I see LF endings but checking this out on Windows I see CRLF endings so this behavior is correct. This diff is displaying index changes which does move from CRLF->LF. I didn't see any test failures on Linux and these files will not have changed on Windows so this should be good.

  rG LLVM Github Monorepo



More information about the cfe-commits mailing list