Re: [1.8.0] Recursively checkout, merge and reset populated submodules

From: Marc Branchaud <marcnarc@xiplink.com>
Date: Feb 21, 2011, 16:13 UTC
Message-ID: <4D628F21.3050808@xiplink.com>
In-Reply-To: <4D5FF6E7.8090104@web.de>

On 11-02-19 11:59 AM, Jens Lehmann wrote:

Show 18 quoted lines

> 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.