git line endings : renormalize does not seem to checkout the right line endings

问题

I decided to set my line endings the Right Way via a .gitattributes file as detailed for instance here - so I set the core.autocrlf to false and created and committed a .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

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

Thanks

回答1:

It must be a bug. It is strange it is not fixed or reported really - this whole mess is about windows, and it does not work precisely on windows ? Moreover there is no mention of it anyplace (?)

EDIT : Installed from the mingw "latest repository catalogues" - g++, gcc, ObjC + the MinGW Developer Toolkit and MSYS-1.0.11. Same behavior. Whenever I try to commit a CRLF file I get the CRLF will be replaced with LF (on checkout is implied) warning.

EDIT 2 : seems about to be fixed

EDIT 3: This has been fixed in Git 1.8.4.

回答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 may be either "lf" or "crlf". Native is for the core.eol config setting.

Set core.autocrlf false to take explicit control of normalization. Now only files you mark with the text attribute will undergo normalization.

Either set the eol attribute explicitly to lf or crlf for specific filetypes (eg: shell scripts may require lf to work on unix, .csproj files may require crlf on windows). If the eol attribute is unset the value of core.eol should be used. If you set core.eol to crlf then your text files will get crlf endings.

Here is a git test script to illustrate this (run 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 config and attributes, with Git for Windows 1.8.0 both files are normalized after the reset and contain crlf line endings.

Where a bug may exist is that if the core.eol variable is left unset (or set to 'native') this test fails as the files are normalized to lf line endings in this case. The path you have mentioned above does not help this situation either. So from my testing, you must explicitly set core.eol to crlf to have your planned approach be successful.

来源：https://stackoverflow.com/questions/13531988/git-line-endings-renormalize-does-not-seem-to-checkout-the-right-line-endings

标签

git

line-endings

gitattributes