The only specific reasons to set autocrlf
to true
are:
- avoid
git status
showing all your files asmodified
because of the automatic EOL conversion done when cloning a Unix-based EOL Git repo to a Windows one (see issue 83 for instance) - and your coding tools somehow depends on a native EOL style being present in your file:
- for instance, a code generator hard-coded to detect native EOL
- other external batches (external to your repo) with regexp or code set to detect native EOL
- I believe some Eclipse plugins can produce files with CRLF regardless on platform, which can be a problem.
- You code with Notepad.exe (unless you are using a Windows 10 2018.09+, where Notepad respects the EOL character detected).
Unless you can see specific treatment which must deal with native EOL, you are better off leaving autocrlf
to false
(git config --global core.autocrlf false
).
Note that this config would be a local one (because config isn’t pushed from repo to repo)
If you want the same config for all users cloning that repo, check out “What’s the best CRLF
handling strategy with git?”, using the text
attribute in the .gitattributes
file.
Example:
*.vcproj text eol=crlf
*.sh text eol=lf
Note: starting git 2.8 (March 2016), merge markers will no longer introduce mixed line ending (LF) in a CRLF file.
See “Make Git use CRLF on its “<<<<<<< HEAD” merge lines”