I have Windows machine with VS project and I use both Visual Studio and tools from Cygwin environment including Git. Sometimes I get different line endings in files after editing. I want simple solution to check files' line ending consistency before they go to the repo. Git's core.safecrlf
is the right thing I suppose.
Now I have a strange behavior:
Files A
and B
with following parameters:
$file A
A: HTML document, UTF-8 Unicode text, with CRLF line terminators
$file B
B: HTML document, UTF-8 Unicode (with BOM) text, with CRLF line terminators
File A is already in repo, file B is new one. Note, both have CRLF line endings. Now try to stage them, core.safecrlf
is true
.
$git add A # ok
$git add B # fails
fatal: CRLF would be replaced by LF in B.
Am using core.safecrlf
correctly? Or maybe I need to write hook to check files?
Notes:
core.autocrlf
feature in Git, added it to tags (Stackoverflow has no tag for core.safecrlf
)EDIT #1: checked out core.autocrlf
- it was input
. Changed to false
, now I can add both files. Why?
According to your later edit core.autocrlf = input
was the original setting. With this setting CRLF
is converted to LF
when checked in to the repository and is kept that way when checked out. This means a non Unix line endings aware editor like Notepad would mess up the appearance of a checked out version of the file. It would be one giant long line.
FWIW core.autocrlf = input
is the preferred setting on Unix systems and using the default cygwin
build probably set it that way. In Windows the recommended settings is core.autocrlf = true
which is what msysgit
recommends
core.safecrlf = true
aborts the conversion of a file if checking out the file will result in a changed and possibly damaged file which would be the case if Notepad was the editor. This is why file B was aborted because it would be messed up in an editor like Notepad. The difference between core.SAFEcrlf
and core.AUTOcrlf
should be noted. It is one of the eyes glazing over
issues in understanding git
line endings
core.autocrlf = false
is don't care mode. It will check in and check out the files exactly as they are, which is why the commits now work. This is not very smart and is not recommended because it causes problems if the files are edited on both Windows and Unix systems and also if another users core.autocrlf
settings differ and change the file endings.
My own preference is to set core.autocrlf
to input
on Windows if all the Windows editors and other text file processing tools on the project are Unix line ending aware, otherwise set it to core.autocrlf = true
for Windows and core.autocrlf = input
for Unix. In any case this approach is outmoded by the superior method of the .gitattributes
file.
The .gitattributes
file method processes files based on the file name and is maintained in all users environments as it is checked out into the working directory like .gitignore
. The settings for as many file names and types as are relevant to your project should be added to .gitattributes
. Your configuration then falls back onto the local core.autocrlf and core.safecrlf settings if the file name is not matched in .gitattributes
. Adding * text=auto
at the top of .gitattributes
will cause git
to do a best guess on file names which are not matched by the later .gitattributes
settings.
This web page, Mind the End of Your Line helped me understand the issue better. You might read for more background on the issue.