Hannu Koivisto <azure@xxxxxx> writes: > Actually, even if .gitattributes were applied in checkout, I think > the whole CRLF support is broken by design because people will have > to remember to use -n in clone, then enable core.autocrlf support > and then checkout. This makes it unneccessarily complicated to I forgot one thing: so what if someone forgets to use -n or just imagines that you can set core.autocrlf afterwards? # Pretend someone does this on Unix mkdir test1 cd test1 git init echo "*.c crlf" > .gitattributes echo -e "foo\nfoo\nfoo" > kala.c git add .gitattributes kala.c git commit -m "Initial checkin." cd .. # Pretend test1 is not a local repository and someone else does this on Windows git clone test1 test2 cd test2 git config core.autocrlf true git status # On branch master nothing to commit (working directory clean) Now the user would have to know that even though git status claims everything is ok, that is not the case. The user would have to know to say (according to #git): rm .git/index git reset --hard Just for the record, when I started to learn git, one of the first questions I had was "how do I undo checkout?" It wasn't until now that I learned I need to remove .git/index (in addition to all files). -- Hannu -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
