Re: [RFC] extending pathspec support to submodules

[Brandon Williams <bmwill@google.com>]

On Thu, Sep 15, 2016 at 3:08 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
>  * Your program that runs in the top-level superproject still needs
>    to be able to say "this pathspec from the top cannot possibly
>    match anything in the submodule, so let's not even bother
>    descending into it".
>

Yes, we would need to first check if the submodule is a prefix match to the
pathspec.  ie a submodule 'sub' would need to match the pathspec 'sub/somedir'
or '*.txt' but not the pathspecs 'subdirectory' or 'otherdir'

> > >    So we may have to rethink what this option name should be.  "You
> > >    are running in a repository that is used as a submodule in a
> > >    larger context, which has the submodule at this path" is what the
> > >    option tells the command; if any existing command already has
> > >    such an option, we should use it.  If we are inventing one,
> > >    perhaps "--submodule-path" (I didn't check if there are existing
> > >    options that sound similar to it and mean completely different
> > >    things, in which case that name is not usable)?
> >
> > Would it make sense to add the '--submodule-path' to a more generic
> > part of the code? It's not just ls-files/grep that have to solve exactly this
> > problem. Up to now we just did not go for those commands, though.
>
> Yes I think so, since it should also handle starting from a submodule
> with a pathspec to the superproject or other submodule. In case we
> go with my above suggestion I would suggest a more generic name since
> the option could also be passed to processes handling the superproject.
> E.g. something like --module-prefix or --repository-prefix comes to my
> mind, not checked though.

Yeah we may want to come up with a more descriptive option name now which can
be generally applied, especially if we are going to continue adding submodule
support for other commands.

-Brandon