I am having some trouble with the core.autocrlf feature in Git ...
In our team, we are moving from a pure Windows to a mixed Windows and Linux environment (out of necessity). We have a codebase we have been tracking in Git for years. It contains both files with LF and CRLF line endings. (As we were a Windows-only shop, we never really paid attention to it. The LF files are probably a result of using MSYS2/Cygwin/MinGW tools). It would be desirable to only have LF line endings on Linux and only have CRLF line endings on Windows. Now, team members will have to check out the code and work on the files on both Windows and Linux simultaneously. In order to do so, we have enabled the core.autocrlf setting on all computers. But I notice that when I check our repo out on Linux, there's still plenty of CRLF files. To me then it appears Git is not respecting the auto.crlf setting.
My question is now: does Git apply auto.crlf retroactively or will Git only do line ending conversions going forward? Do I need to "re-normalize" my repositories?
Thank you in advance!
If you set core.autocrlf on a Windows machine, Git will ensure that new files will automatically have Unix-style (LF) line endings when they get committed to the Git Index. However, if you checkout a repo that has files already committed with CRLF line endings, Git won't change their line endings automatically to LF; it will only do that for existing files if you specify --renormalize when doing a git add.
This means that files will remain with their Windows-style (CRLF) line endings in the Git Index and since Git never converts from CRLF to LF at checkout, this means that your Linux machines will not be able to checkout files with LF in them until those files are renormalized in the Index.
To help you diagnose which files need to be renormalized, you can have a look at the output of this command:
git ls-files --eol
(i/... will give you the line endings in the Git Index, and w/... is for the working directory, ie. your machine.)