Hi, If the LF is forced by anything (git config, gitattribute, checkstyle, etc), what will happen to the file based tests where there is a purposefully CRLF line ending, because the test covers a fixed issue that was specifically related to windows files. E.g. in CSV. I mean files here for example: commons-csv/src/test/resources/org/apache/commons/csv at master · apache/commons-csv · GitHub <https://github.com/apache/commons-csv/tree/master/src/test/resources/org/apache/commons/csv> I'm not 100% sure this is a valid concern at the moment, but I think it could be.
David Alex Herbert <alex.d.herb...@gmail.com> ezt írta (időpont: 2025. jan. 18., Szo, 19:14): > On Sat, 18 Jan 2025 at 18:05, Piotr P. Karwasz <pi...@mailing.copernik.eu> > wrote: > > > Hi Alex, > > > > On 18.01.2025 18:06, Alex Herbert wrote: > > > $ echo "* text=auto" >>.gitattributes > > > $ rm .git/index # Remove the index to force Git to > > > $ git reset # re-scan the working directory > > > $ git status # Show files that will be normalized > > > $ git add -u > > > $ git add .gitattributes > > > $ git commit -m "Introduce end-of-line normalization" > > > > Without dealing with Git internals, you can also do: > > > > $ git add --renormalize * > > > > IIRC that is what it used to state on the git documentation. Strangely the > page I quoted was linked from a Google search result. I assumed it was the > latest but it is for 2.6.7. If I remove that version number you get the > action as suggested [1]: > > $ echo "* text=auto" >.gitattributes > $ git add --renormalize . > $ git status # Show files that will be normalized > $ git commit -m "Introduce end-of-line normalization" > > > Alex > > [1] https://git-scm.com/docs/gitattributes >
