Re: check-attr doesn't respect recursive definitions
- From
- Jan Larres <jan@majutsushi.net>
- Date
- Apr 3, 2013, 10:05 UTC
- Message-ID
- <slrnklnvo6.jdl.jan@majutsushi.net>
- In-Reply-To
- <20130402191641.GB17784@sigill.intra.peff.net>
Thanks for the clarifications. Just a quick comment about the summary:
Jeff King <peff@peff.net> wrote:
Show 18 quoted lines
> Yeah, I had the same thought. So you would have to either: > > 1. Hook the feature into git-archive, which knows about how it > recurses, and can report the correct set of paths. > > or > > 2. Tell check-attr (or some post-processor) to apply the attribute to > elements below the path (or possibly to prune out such paths). This > is not the same as recursive application, because you cannot negate > it (i.e., you actually find out the final attrs for both "foo" and > "foo/bar", and then say "the attr for 'foo' overrides the attr for > 'foo/bar'". > > I posted a patch for (1), but it felt not-very-general. But (2) also > feels gross and not very general. Even though it could in theory be used > for things besides git-archive, it is really just applying git-archive's > pruning rule, which other programs likely don't care about.
I actually think the first approach is not such a bad idea, it would make "archive" more of a general-purpose archiving tool/helper for the repository rather than just something for the special cases of tars and zips. But I guess that's somewhat subjective.
Cheers, Jan