On Sun, Nov 02, 2008 at 06:33:51PM +0200, Hannu Koivisto wrote: > It seems that, for example, glob pattern *.s matches files with .sh > extension at least with checkout and reset --hard but git status > thinks otherwise: I think your analysis is incorrect. I will try to explain what is happening. > mkdir test > cd test > git init > echo -e "*.sh -crlf\n*.s crlf" > .gitattributes > echo -e "foobar\nfoobar\nfoobar" > kala.s > echo -e "foobar\nfoobar\nfoobar" > kala.sh > git add .gitattributes kala.s kala.sh > git commit -m "Foo." OK, so here we have two files, one of which we are telling git is text and one of which we are telling git is not text. Since we don't have autocrlf set at all, of course nothing happens here. > git clone -n test test2 And here we clone without checking out, so there are no files yet. > cd test2 > git config core.autocrlf true > git checkout And now we do check out the files, with autocrlf applied. But what are we left with? When I run this, _both_ files were detected as text and have CRLF line endings. So here I think is where git didn't do what you expected: kala.sh should not have had CRLF conversion applied. This is a known limitation of the attributes mechanism: it only reads from .gitattributes in the filesystem (or from .git/info/attributes), and not from the tree that is being checked out. This is something that should be addressed, but nobody has stepped up with a patch yet (though there has been some preliminary discussion). > git status > > # On branch master > # Changed but not updated: > # (use "git add <file>..." to update what will be committed) > # (use "git checkout -- <file>..." to discard changes in working > # directory) > # > # modified: kala.sh > # > no changes added to commit (use "git add" and/or "git commit -a") So yes, this status makes perfect sense, then. The file "kala.sh" has CRLFs in the filesystem, but we have told git that it is not a file which gets converted. So it looks like those CRs have been added. The problem, again, is that we have inconsistently applied the gitattributes. They were _not_ applied during checkout (because .gitattributes did not exist yet), but they _are_ being applied here. To "fix" this, you can then do a "git reset --hard" which will respect your .gitattributes (since it is now checked out). And further file creation and checkout should work OK. -Peff -- 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
