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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 12, 2021, 04:20 UTC
Message-ID: <xmqqeeaz70ph.fsf@gitster.g>
In-Reply-To: <pull.1006.v5.git.1628736366133.gitgitgadget@gmail.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).