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 -- 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