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

[Emily Shaffer <emilyshaffer@google.com>]

On Thu, Aug 12, 2021 at 09:34:47PM -0700, Junio C Hamano wrote:
> 
> 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.

Yeah, since writing my reply I was very helpfully reinformed on the
convention around 'feature.experimental' by Jonathan N off-list. Thanks
for being patient with me.

I think the right move, then, is to explore whether your suggestion in
https://lore.kernel.org/git/xmqqeeaxw28z.fsf%40gitster.g is appropriate
- I have the sense that it is, but I want to make sure to think it
through before I say so for sure. 

 - Emily