Re: check-attr doesn't respect recursive definitions

On Sat, Mar 30, 2013 at 09:45:51AM +0000, Jan Larres wrote:

I am trying to write a custom archiving script that checks the
export-ignore attribute to know which files from an ls-files output it
should skip. Through this I noticed that for files in directories for
which the export-ignore (or any other) attribute is set, check-attr
still reports 'unspecified'. More precisely:

$ git init test
Initialized empty Git repository in /home/jan/test/.git/
$ cd test
$ mkdir foo
$ touch foo/bar
$ echo "foo export-ignore" > .gitattributes
$ git check-attr export-ignore foo
foo: export-ignore: set
$ git check-attr export-ignore foo/bar
foo/bar: export-ignore: unspecified

I would expect the last command to also report 'set'. I've also tried
other patterns like 'foo/' and 'foo*', but it didn't make any
difference. Is this expected behaviour? It does make checking the
attributes of single files somewhat more difficult.

Yes, it is the expected behavior, though I cannot offhand think of
anything that would break if we did apply it recursively.

git-archive ignores the directory as expected, but unfortunately it
doesn't have an option to just list the files it would archive instead
of actually archiving them.

Yes, git-archive feeds the directories into the attribute machinery as
it traverses the tree, so it actually checks for attributes of "foo"
before recursing. You can do the same, but I agree it is quite a bit
more annoying than just piping "ls-files -z" into "check-attr --stdin
-z".

-Peff