Re: [PATCH v5] clone: set submodule.recurse=true if user enables feature.experimental flag

Philippe Blain <levraiphilippeblain@gmail.com> writes:

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.