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

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

"Mahi Kolla via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Mahi Kolla <mahikolla@google.com>
>
> Currently, when running 'git clone --recurse-submodules', developers do not expect other commands such as 'pull' or 'checkout' to run recursively into active submodules. However, setting 'submodule.recurse' to true at this step could make for a simpler workflow by eliminating the '--recurse-submodules' option in subsequent commands. To collect more data on developers' preference in regards to making 'submodule.recurse=true' a default config value in the future, deploy this feature under the opt in feature.experimental flag.

Please wrap overlong lines in your proposed log message to say 70 or
so columns.

>
> Since V1: Made this an opt in feature under the experimental flag. Updated tests to reflect this design change. Also updated commit message.

This does not belong to the commit log message proper.  Noting the
difference between the version being submitted and the pervious one
this way is a way to help reviewers and is very much appreciated,
but please do so below the three-dash line below your sign-off.

> Signed-off-by: Mahi Kolla <mahikolla@google.com>
> ---
>     clone: set submodule.recurse=true if feature.experimental flag enabled

The proposed approach misuses feature.experimental flag, which was
designed to turn on many new features at once.  The features covered
by the flag share one common trait: they all have gained consensus
that in the longer term we would hopefully be able to make it on by
default, and give early adopters an easy way to turn them all on.

I do not think setting submodule.recurse=true upon "clone --recurse"
falls into that category just yet.  If we were to make this opt-in,
we'd want a separate flag, so that those early adopters who are
dogfooding other features that have consensus that they are
hopefully the way of the future won't have to be forced into this
separate feature.

Perhaps a separate (and new) configuration variable (in ~/.gitconfig
perhaps) can be used as that opt-in flag (I wonder if the existing
submodule.recurse variable can be that opt-in flag, though).