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