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

[Junio C Hamano <gitster@pobox.com>]

Emily Shaffer <emilyshaffer@google.com> writes:

> It seems surprising to me that a user would want to clone with all the
> submodules fetched *without* intending to then use
> superproject-plus-submodules together recursively. I would like to hear
> more about the use case you have in mind, Junio.

You may need full forest of submodules with the superproject to
build your ware (i.e. you'd probably want to clone and fetch-update
them), but you may only be working on the sources in a small subset
of submodules and do not need your recursive grep or diff to go
outside that subset, for example.  You'd need to ask the people who
recursively clone and not set submodule.recurse to true (I am not
among them).

> One scenario that did come to mind when I discussed this with Mahi is
> that a user may provide a pathspec to --recurse-submodules (that is,
> "yes, this repo has submodules a/ and b/, but I only care about the
> contents of submodule a/") - and in that case, --recurse-submodules
> seems to do the right thing with or without Mahi's change.

Please be a bit more specific about "the right thing".  Do you mean
"the submodules that matched the pathspec gets recursed into by
later operations"?

If so, "git clone --resurse-submodules=. $from_there" may perhaps be
the "there is no way to we make this opt-in?" I have been asking
about (not "asking for")?

> It seemed to me that trying out this change on feature.experimental flag
> was the right approach, because users with that flag have already
> volunteered to be testers for upcoming behavior changes

Yes, if we already have a consensus that a proposed change is
something we hope to be desirable, then feature.experimental is a
good way to see if early adopters can find problems in their real
world use, as these volunteers may include audiences with different
use pattern from the original advocates of a particular feature, who
might have dogfooded the new feature to gain consensus that it may
want to become the default.

By the way, I am not fundamentally opposed to the feature being
proposed.  I would imagine that such a feature would be liked by
those who want to keep things simpler.  I however am hesitant to see
it pushed too hastily without considering if it harms existing users
with different preferences.

IOW, I was primarily reacting to the apparent wrong order in which
things are being done, first throwing this into feature.experimental
before we have gathered enough confidence that it may be a good
thing to do by having it in shipped version as an opt-in feature.

Thanks.