On Wed, Nov 20, 2019 at 08:44:52AM -0800, M Lewis wrote:
> When running 'git archive', the .gitattributes file is used to determine
> paths that should be ignored when building the archive by using
> 'export-ignore'.
> But it would be useful to include certain sub-paths in the ignored path.
Yeah, that seems like a reasonable goal, and I think we can make it
work, but the syntax is slightly different.
> The git-attribute document says a dash '-' prefix should unset the
> attribute. It should work with 'export-ignore'
>
> So if I want for example '/mostly_unuseful/needed_a' in my archive, I
> should be able to specify that in my .gitattributes file like this:
>
> /mostly_unuseful export-ignore # do not archive
> /mostly_unuseful/needed_a -export-ignore # do add to archive
> /mostly_unuseful/needed_b -export-ignore # do add to archive
It doesn't work because the attributes are not applied recursively[1];
they are applied to the path you specified. By putting the attribute on
"mostly_unuseful", that doesn't say anything about "needed_a" (from the
perspective of the attributes system). So removing it from that path
likewise does nothing; the attribute is still set on the directory.
Instead, if you write it like this:
/mostly_unuseful/** export-ignore
/mostly_unuseful/needed_a -export-ignore
/mostly_unuseful/needed_b -export-ignore
Then the attributes are applied directly to the file paths in the first
line, and the subsequent lines counteract them. This does mean that the
subdirectory itself isn't marked as export-ignore, and will always be
included (as an empty directory if need be, though of course in your
example we do actually end up with some files in it).
Now obviously there is recursion happening inside git-archive, as it
walks the tree. And the current behavior is that it sees the ignored
subtree and doesn't walk into it at all. So it _could_ make your
original example work by actually searching within the tree for any
paths marked -export-ignore, and including the directory if and only if
it has unignored entries.
I can't offhand think of anything that would break if we started doing
that, but I haven't thought too hard. And given that there's already a
solution using `**`, it might not be worth it.
-Peff
[1] If you're curious, there's some philosophical discussion about this exact issue in
https://public-inbox.org/git/7v1uasg8e0.fsf@xxxxxxxxxxxxxxxxxxxxxxxx/
