Brandon Williams <bmwill@xxxxxxxxxx> writes:
> Well maybe...I don't really know much about how the prefix interacts in
> every scenario but would what you describe still work if we are in a sub
> dir of the superproject (which contains other directorys and perhaps a
> submodule) and execute a --recurse-submodules command in the
> subdirectory? I suspect we don't want to force users to be in the root
> directory of the project in order to use --recurse-submodules.
You need to remember "must be at the top" is relevant only to the
command that is invoked with --super-prefix, not the recursive one
that drives such a process.
Suppose your superproject is organized like so:
- file-at-top
a/file-in-A
a/b (submodule)
a/b/file-at-top-of-B
c/ (submodule)
c/file-at-top-of-C
If you are in a subdirectory of your superproject, say, a/,
cd a && git ls-files --recurse-submodules -- "b*"
I would expect we would recurse into the submodule at "a/b" and find
"b/file-at-top-of-B". What does the internal invocation to do so
would look like? I would think "git -C b --super=b ls-files" that
is run from "a".
Your code would is already prepared to find "file-at-top-of-B" in
the index of the submodule, prepend "b/" to it and report the result
as "b/file-at-top-of-B" when such a call is made, I think.
Now, can you refer to c/ and c/file-at-top-of-C while sitting at a/?
cd a && git ls-files --recurse-submodules -- "../c*"
would be the top-level invocation. This would iterate over the
index of the superproject, trying to find what matches "c*" (or,
"../c*" relative to "a" i.e. where you are), find that 'c' that is a
submodule, and invoke "git -C ../c --super=../c ls-files"
internally, I would imagine. I think your code is prepared to
accept this case as well.
In any case, the "must be at the top" does not come into the picture
at all for the end-user interaction, i.e. invocation of the command
that is told to recurse into submodules, so we'd be OK.