I have a Git repository that is accessed from both Windows and OS X, and that I know already contains some files with CRLF line-endings. As far as I can tell, there are two ways to deal with this:
Set
core.autocrlftofalseeverywhere,Follow the instructions here (echoed on GitHub's help pages) to convert the repository to contain only LF line-endings, and thereafter set
core.autocrlftotrueon Windows andinputon OS X. The problem with doing this is that if I have any binary files in the repository that:- are not correctly marked as binary in gitattributes, and
- happen to contain both CRLFs and LFs,
they will be corrupted. It is possible my repository contains such files.
So why shouldn't I just turn off Git's line-ending conversion? There are a lot of vague warnings on the web about having core.autocrlf switched off causing problems, but very few specific ones; the only that I've found so far are that kdiff3 cannot handle CRLF endings (not a problem for me), and that some text editors have line-ending issues (also not a problem for me).
The repository is internal to my company, and so I don't need to worry about sharing it with people with different autocrlf settings or line-ending requirements.
Are there any other problems with just leaving line-endings as-is that I am unaware of?
ベストアンサー1
The only specific reasons to set autocrlf to true are:
- avoid
git statusshowing all your files asmodifiedbecause 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「