On 11-02-19 11:59 AM, Jens Lehmann wrote: > Proposal: > When switching branches, merging or resetting the work tree of > populated submodules should be checked out too according to the > commit recorded in the superproject. Make this the default for > porcelain and optional for plumbing. > > The same safety precautions that are used for files in the > superproject apply to the changes present in the submodules, > no local modifications may be overwritten unless -f is used. > When the "update" config option is set to "merge" or "rebase" > the submodule will be left unchanged. > > The "update" config option will learn a new value "none" to let > the user turn off this behavior for single submodules. A global > config option and the command line parameter "--recurse-submodules" > will also be added. This change will remove the need to call "git > submodule update" for all populated submodules (except those who > use the "update=merge" or "update=rebase" configuration settings). A big +1 from me for all the submodule work -- thanks Jens! Could you clarify the proposal a bit? A few questions occurred to me as I read it: * How is the initial set of populated submodules set up during a clone operation? Specifically, how would the origin repo specify which submodules to recursively clone? (My understanding is that the origin's .gitmodules file, as it exists in whatever branch is being cloned, would specify submodule.<name>.update values, and those would drive the recursion.) * Which values of submodule.<name>.update would enable/disable recursion during a clone? Would just "checkout" enable it, or should "merge" and "rebase" also trigger recursion when cloning? * What happens when a clone's user manually populates one of the other submodules that wasn't part of the initial set? Automatic recursion into this newly-populated submodule is controlled by the setting of the global recurse-submodules option, right? * What are the possible values of the global recurse-submodules option? Here's what I came up with: all -- Always recurse populated -- Only recurse into *all* currently-populated submodules respect -- Respect each submodule's "update" option (better name?) none -- Never recurse * What will happen when I start checked out at commit A, with a populated submodule, then check out commit B where that submodule doesn't exist, then return to commit A? How will whatever recursion settings I had at the start be preserved? M. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html