Brandon Williams <bmwill@xxxxxxxxxx> 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 apposed > 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 simplify things. * 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 would: - 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)? Thanks.