Re: [PATCH 05/15] ref-filter.c: parameterize match functions over patterns

From: Taylor Blau <me@ttaylorr.com>
Date: May 9, 2023, 20:13 UTC
Message-ID: <ZFqpZrwiKARsM53t@nand.local>
In-Reply-To: <xmqqmt2e4fia.fsf@gitster.g>

On Mon, May 08, 2023 at 03:36:45PM -0700, Junio C Hamano wrote:

Show 17 quoted lines

> > @@ -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.

Show 5 quoted lines

> 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