Re: [PATCH 2/2] ls-files: add pathspec matching for submodules

[Junio C Hamano <gitster@pobox.com>]

Brandon Williams <bmwill@google.com> writes:

> Pathspecs can be a bit tricky when trying to apply them to submodules.
> The main challenge is that the pathspecs will be with respect to the
> super module and not with respect to paths in the submodule.  The
> approach this patch takes is to pass in the identical pathspec from the
> super module to the submodule in addition to the submodule-prefix, which
> is the path from the root of the super module to the submodule, and then
> we can compare an entry in the submodule prepended with the
> submodule-prefix to the pathspec in order to determine if there is a
> match.
>
> This patch also permits the pathspec logic to perform a prefix match against
> submodules since a pathspec could refer to a file inside of a submodule.
> Due to limitations in the wildmatch logic, a prefix match is only done
> literally.  If any wildcard character is encountered we'll simply punt
> and produce a false positive match.  More accurate matching will be done
> once inside the submodule.  This is due to the super module not knowing
> what files could exist in the submodule.

Sounds sensible.  Just a minor nit in terminology, but I think we
fairly consistently say "a superproject contains submodules" (run
"git grep -E 'super *(module|project)'").

I'd suggest s/super module/superproject/ for consistency.

> diff --git a/dir.c b/dir.c
> index 0ea235f..9df6d36 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -207,8 +207,9 @@ int within_depth(const char *name, int namelen,
>  	return 1;
>  }
>  
> -#define DO_MATCH_EXCLUDE   1
> -#define DO_MATCH_DIRECTORY 2
> +#define DO_MATCH_EXCLUDE   (1<<0)
> +#define DO_MATCH_DIRECTORY (1<<1)
> +#define DO_MATCH_SUBMODULE (1<<2)
>  
>  /*
>   * Does 'match' match the given name?
> @@ -283,6 +284,29 @@ static int match_pathspec_item(const struct pathspec_item *item, int prefix,
>  			 item->nowildcard_len - prefix))
>  		return MATCHED_FNMATCH;
>  
> +	/* Perform checks to see if "name" is a super set of the pathspec */
> +	if (flags & DO_MATCH_SUBMODULE) {
> +		/* Check if the name is a literal prefix of the pathspec */
> +		if ((item->match[namelen] == '/') &&
> +		    !ps_strncmp(item, match, name, namelen))
> +			return MATCHED_RECURSIVELY;

An example of this test would be to match pathspec "sub/file" with
submodule path "sub"?

item->match[namelen] is accessed without checking if item->match[]
is long enough here; shouldn't item->len be checked before doing
that?

> +		/*
> +		 * Here is where we would perform a wildmatch to check if
> +		 * "name" can be matched as a directory (or a prefix) against
> +		 * the pathspec.  Since wildmatch doesn't have this capability
> +		 * at the present we have to punt and say that it is a match,
> +		 * esentially returning a false positive (as long as "name"
> +		 * matches upto the first wild character).
> +		 * The submodules themselves will be able to perform more
> +		 * accurate matching to determine if the pathspec matches.
> +		 */
> +		if (item->nowildcard_len < item->len &&
> +		    !ps_strncmp(item, match, name,
> +				item->nowildcard_len - prefix))
> +			return MATCHED_RECURSIVELY;

An example of this test would be to match pathspec "su?/file" with
submodule path "sub", where the substring up to nowildcard_len is
the leading literal string "su" that must match with the path (in
other words, a path "sib" will not match "su?/file").

> +	}
> +

Hmph, isn't this the one that is allowed produce false positive but
cannot afford to give any false negative?  It feels a bit strange
that the code checks two cases where we can positively say that it
is worth descending into, and falling through would give "no this
will never match".  That sounds like invitation for false negatives.

IOW, I would have expected

        if (flags & DO_MATCH_SUBMODULE) {
                if (may match in this case)
                        return MATCHED_RECURSIVE;
                if (may match in this other case)
                        return MATCHED_RECURSIVE;
                ...
                if (obviously cannot match in this case)
                        return 0;
                if (obviously cannot match in this other case)
                        return 0;
                /* otherwise we cannot say */
                return MATCHED_RECURSIVELY;
        }

as the general code structure.

Fully spelled out,

        if (flags & DO_MATCH_SUBMODULE) {
                /* Check if the name is a literal prefix of the pathspec */
                if (namelen < item->len &&
                    item->match[namelen] == '/' &&
                    !ps_strncmp(item, match, name, namelen))
                        return MATCHED_RECURSIVE;

                /* Does the literal leading part have chance of matching? */
                if (item->nowildcard_len < item->len &&
                    namelen <= item->nowildcard_len &&
                    ps_strncmp(item, match, name, namelen))
                        return 0; /* no way "su?/file" can match "sib" */

                /* Otherwise we cannot say */
                return MATCHED_RECURSIVELY;
        }

or something like that.  There may be other "obviously cannot match"
cases we may want to add further.

Thanks.