On Thu, Sep 15, 2016 at 3:08 PM, Junio C Hamano <gits...@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.