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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 13, 2021, 04:34 UTC
Message-ID: <xmqqpmuiynbs.fsf@gitster.g>
In-Reply-To: <YRW0pGXXWnY7C470@google.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).

Show 5 quoted lines

> 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.