Mahi Kolla <mahikolla@xxxxxxxxxx> writes: >> Is it possible to avoid changing the behaviour unconditionally and >> potentially breaking existing users by making it an opt-in feature, >> e.g. "git clone --recurse-submodules" would work as the current >> users would expect, while "git clone --recurse-submodules=sticky" >> would set submodule.recurse to true, or something? > > As mentioned, the `submodule.recurse=true` will only apply to active > submodules specified by the user. Setting this config value when the > user runs their initial `git clone` minimizes the number of times a > developer must use the `--recurse-submodule` option on other commands. > > However, this is a behavior change that may be surprising for > developers. To ensure a smooth rollout and easy adoption, I think > adding a message using an `advice.*` config setting would be useful. It may be better than nothing, but that still is a unilateral behaviour change. Can't we come up with a way to make it an opt-in feature? I've already suggested to allow the "--recurse-submodules" option of "git clone" to take an optional parameter (e.g. "sticky") so that the user can request configuration variable to be set, but you seem to be ignoring or skirting it. Even though I am not married to the "give optional parameter to --recurse-submodules" design, unconditionally setting the variable, with or without advice or warning, is a regression we'd want to avoid.
