Git line endings: renormalize doesn't seem to check for proper line endings

Question

I decided to set my lines in the right order using the .gitattributes file, as described, for example, here ), so I set core.autocrlf to false and created and committed the .gitattributes file:

 *.java text eol=native *.jsp text eol=native *.css text eol=native *.html text eol=native *.js text eol=native *.xml text eol=native *.sql text eol=native *.MF text eol=native # git files *.gitignore text eol=native *.gitattributes text eol=native #eclipse files *.classpath text eol=native *.project text eol=native *.prefs text eol=native *.properties text eol=native 

Then I released git rm --cached -r . and then git reset --hard (also tried git checkout HEAD ) as suggested here . Now all files have LF line endings. Shouldn't be CRLF? What am I missing? I am in windows 7, git version 1.8.0.msysgit.0 .

thanks

Answer 1

It must be a mistake . It is strange that this is not fixed or is not actually reported - all this mess is windows, and it does not work on windows? Moreover, there is no mention of this anywhere (?)

EDIT: Installed from the latest mingw repository directories - g ++, gcc, ObjC + MinGW and MSYS-1.0.11 Developer Toolkit. The same behavior. Whenever I try to transfer a CRLF file, I get that the CRLF will be replaced by the LF warning (when checking).

EDIT 2: seems to be fixed

EDIT 3: This has been fixed in Git 1.8.4.

Answer 2

For what you are trying to do, I think you need the following. Note that the eol attribute according to the gitattributes man page can be either "lf" or "crlf". Native is for configuring core.eol.

Set core.autocrlf false to explicitly control normalization. Now only files marked with the text attribute will undergo normalization.

Either set the eol attribute explicitly to lf or crlf for certain types of files (for example: shell scripts may require lf to work on unix, .csproj files may require crlf on windows). If the eol attribute is not set, use the value core.eol. If you install core.eol in crlf then your text files will get crlf endings.

Here is an example git test script to illustrate this (from git / t /):

 #!/bin/sh test_description='check native crlf setting' . ./test-lib.sh has_cr() { tr '\015' Q <"$1" | grep Q >/dev/null } test_expect_success 'test native elf' ' printf "*.txt text\n" > .gitattributes printf "one\r\ntwo\r\nthree\r\n" > filedos.txt printf "one\ntwo\nthree\n" > fileunix.txt git init && git config core.autocrlf false && git config core.eol crlf && git add . && git commit -m "first" && rm file*.txt && git reset --hard HEAD && has_cr filedos.txt && has_cr fileunix.txt ' test_done 

With the above configuration and attributes with git for Windows 1.8.0, both files are normalized after reset and contain crlf line endings.

Where an error may exist is that if the core.eol variable is not set (or set to "native"), this test will fail because the files in this case are normalized to the end of the lf line. The path you mentioned above does not help either. Therefore, from my testing, you should explicitly specify core.eol in crlf so that your planned approach is successful.