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