Philippe Blain <levraiphilippeblain@xxxxxxxxx> writes:
> Here I think you are confusing submodule.active (which takes a pathspec)
> and submodule.recurse (which takes a boolean).
Sigh, but I have to agree with you.
I really hoped that in a recursive clone of a repository with two
submodules A and B, when made with --recurse-submodules=A, "git grep
." would look for things in the superproject and submodule A as
Emily seemed to have meant by her "the right thing", but you are
correct. We only set .active but we do not set .recurse, so "git
grep ." in the superproject does not descend into neither
submodules without being told.
If it did "the right thing" as Emily said, it would have been much
easier to justify the change being proposed as a simple fix for the
bug that --recurse-submodules without pathspec does one thing
(i.e. setting things up not to recurse for later "grep" etc.") and
the same option with "everything matches" pathspec "." does a
different thing (i.e. always to recurse).
The discrepancy would have given us an excuse, an argument for
changing the behaviour for the former to match the latter. Some
users may have deliberately built their workflow relying on the
distinction and the result still may give them a regression, but at
least it would have gave us a viable justification:
A command run without pathspec means the entire tree and it is
the same as running it with pathspec '.' in the rest of Git, but
the way "git clone --recurse-submodules" handles its optional
pathspec is inconsistent. Treat "clone --recurse-submodules"
without pathspec as if it came with pathspec '.' and give the
same configuration.
But unfortunately it does not seem to be the case.
