Re: .gitattributes glob matching broken

[Jeff King <peff@peff.net>]

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