Re: check-attr doesn't respect recursive definitions

From: Jeff King <peff@peff.net>
Date: Apr 2, 2013, 14:31 UTC
Message-ID: <20130402143130.GC23828@sigill.intra.peff.net>
In-Reply-To: <slrnkldd3g.1l4.jan@majutsushi.net>

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

Show 21 quoted lines

> 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