Re: check-attr doesn't respect recursive definitions

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 2, 2013, 17:16 UTC
Message-ID: <7v1uasg8e0.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130402165128.GA19712@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 18 quoted lines

> On Tue, Apr 02, 2013 at 09:43:30AM -0700, Junio C Hamano wrote:
>
>> > In some systems, yes, but git does not have any notion of "doc/" as an
>> > item (after all, we track content in files, not directories), so I do
>> > not see what it means to specify a directory except to say "everything
>> > under it has this property".
>> 
>> That was true back when gitattributes (and ignore) was defined to
>> apply only to the paths we track.  But export-ignore abuses the
>> attrtibute system, allows a directory to be specified in the match
>> pattern, and we declared that is a kosher use by the patch that
>> caused 1.8.1.X regression, no?  So "Git does not have any notion of
>> "doc/' as an item" is no longer true, I think.
>
> Yes, but as I explained later, the meaning of "apply an attribute to
> dir" in such cases is always equivalent to "apply attribute
> recursively to dir/*". So I do not think we are violating that rule to
> recursively apply all attributes.

I think this is where we disagree. Attribute does not recursively apply in general. It was _never_ designed to (and that is the authoritative answer, as I was who designed it in Apr 2007 ;-)).

It is not even true to say that "archive" applies export-ignore to the directory recursively, with or without the recent change. Would it allow everything but dir/file to be excluded and still dir/file to be included in the archive if you have a .gitattribute file like this?

	dir/ export-ignore
        dir/file !export-ignore

I do not think so.

If we _were_ living in an alternate universe where we did not have the .gitignore file and instead expressed what it does with an "ignore" attribute, then having "dir" in the top-level .gitignore file and "!file" in the .gitignore file in "dir/" directory may be equivalent to having

	dir/ ignore
        dir/file -ignore

in your .gitattribute, and we would want to ignore dir/other while including dir/file in the "may be interesting" paths.

The point is, yes, we could choose to define individual attribute keys to apply recursively, but in general attributes were designed not to recurse, and no existing attribute recurses.

> But let's take a step back. I think Jan is trying to do a very
> reasonable thing: come up with the same set of paths that git-archive
> would. What's the best way to solve that?

Because the attribute does not recursively apply in general, and it is entirely up to the application and a particular attribute key to decide how the key is applied in the context of the application, "check-attr" by itself cannot know. You need to know how "archive" treats "export-ignore" attribute and then use "check-attr" with that knowledge.

Show 6 quoted lines

> Using:
>
>   git ls-tree --name-only -zrt HEAD |
>   git check-attr --stdin -z export-ignore
>
> means we can find out that "foo/" is ignored.

Yes, and after learning that, we need to reject everything foo/* using the knowledge that "git archive" cuts all subpaths of a path that has "export-ignore" attribute is attached to.