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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html