Brandon Williams <bmw...@google.com> writes:
> You're right that seems like the best course of action and it already falls
> inline with what I did with a first patch to ls-files to support submodules.
> In that patch I did exactly as you suggest and pass in the prefix to the
> submodule and make the child responsible for prepending the prefix to all of
> its output. This way we can simply pass through the whole pathspec (as
> to my original idea of stripping the prefix off the pathspec prior to passing
> it to the child...which can get complicated with wild characters) to the
> childprocess and when checking if a file matches the pathspec we can check if
> the prefix + file path matches.
That's brilliant. A few observations.
* With that change to tell the command that is spawned in a
submodule directory where the submodule repository is in the
context of the top-level superproject _and_ require it to take a
pathspec as relative to the top-level superproject, you no longer
worry about having to find where to cut the pathspec given at the
top-level to adjust it for the submodule's context. That may
* 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".
* Earlier while reviewing "ls-files" recursion, I suggested (and
you took) --output-path-prefix as the option name, because it was
meant to be "when you output any path, prefix this string". But
the suggested name is suboptimal, as it is no longer an option
that is only about "output". A command that runs in a submodule
- enumerate paths in the context of the submodule repository,
- prepend the "prefix" to these paths,
- filter by applying the full-tree pathspec, and
- work on the surviving paths after filtering.
When the last step, "work on", involves just "printing", the
whole path (with "prefix") is sent to the output. If it involves
some operation relative to the submodule repository (e.g. seeing
if it is in the index), the "prefix" may have to be stripped
while the operation is carried out.
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)?