On Mon, May 08, 2023 at 03:36:45PM -0700, Junio C Hamano wrote:
> > @@ -2132,9 +2133,10 @@ static int match_pattern(const struct ref_filter *filter, const char *refname)
> > * matches a pattern "refs/heads/" but not "refs/heads/m") or a
> > * wildcard (e.g. the same ref matches "refs/heads/m*", too).
> > */
> > -static int match_name_as_path(const struct ref_filter *filter, const char *refname)
> > +static int match_name_as_path(const struct ref_filter *filter,
> > + const char **pattern,
> > + const char *refname)
> > {
> > - const char **pattern = filter->name_patterns;
> > int namelen = strlen(refname);
> > unsigned flags = WM_PATHNAME;
> >
>
> These hint that we'd eventually lose .name_patterns member from the
> structure so that we can pass pattern array that is not necessarily
> tied to any instance of a filter?
Right. We'll pass in the excluded patterns in the next commit.
> And we are not there yet, so we hoist the use of .name_patterns
> member one level up to the only caller?
>
> Without seeing how it evolves, we can tell this does not make
> anything break, but we cannot tell how this helps anything (yet).
Hmm. I tried to allude to this in the patch message with the paragraph:
The subsequent patch will add a new array of patterns to match over (the
excluded patterns, via a new `git for-each-ref --exclude` option),
treating the return value of these functions differently depending on
which patterns are being used to match.
Tweak `match_pattern()` and `match_name_as_path()` to take an array of
patterns to prepare for passing either in.
...but I'm happy to add detail or clarify it if you think that these
paragraphs could use it.
Thanks,
Taylor
