On Thu, Jun 22, 2023 at 08:53:53AM -0400, Taylor Blau wrote: > On Thu, Jun 22, 2023 at 08:49:43AM -0400, Taylor Blau wrote: > > I am left wondering: why doesn't the rule pertaining to > > refs/heads/foo/baz show up in the included list? Likewise, what happens > > with refs/heads/bar/baz/quux? It is a child of an excluded rule, so the > > question is which list takes priority. > > > > Mostly, I am wondering if I am missing something that would explain why > > you couldn't modify the above example's excluded list to contain > > something like "!refs/heads/bar/baz/quux", eliminating the need for the > > include list entirely. > > Another potential quirk that I just now thought of: what are the rules > for what can go in the include list? Fully qualified references only? Or > can we have patterns (e.g. refs/foo/bar/*). Presumably you'd want to > have the namespace-stripping operator ^, but not !, since negating an > include rule seems to imply that it should be in the exclude list. Sorry for the long chain of self-replies. I think one clarifying point that I am not sure of yet is whether or not the exclude rules you're talking about are interpreted as patterns (as in transfer.hideRefs) or wildmatch patterns. If they are wildmatch patterns, would it suffice to add the references you *do* want to enumerate to the traversal ahead of time? There is also the hidden_refs member of that struct, so perhaps adding negated entries there would work. Either way, I think emphasizing the difference between ref exclusions as it pertains to traversal, and ref exclusions as it pertains to hiding would greatly help other reviewers of this series. Thanks, Taylor
