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

Am 21.02.2011 17:13, schrieb Marc Branchaud:

On 11-02-19 11:59 AM, Jens Lehmann wrote:
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.)

That is what I have in mind. I tend towards updating all populated
submodules on local operations (like switching branches, merging and so
on) unless configured otherwise, while for cloning me thinks an explicit
"submodule.<name>.update=checkout" or such should be necessary.

(But please note that cloning was not part of my proposal, I was only
talking about the local operations for now ;-)

* 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?

"merge" and "rebase" could do that too, but wait: That would make it
impossible to say "I want his submodule merged/rebased but *not* cloned"
... Hmm, good point, I'll have to think about that some more ...

* 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?

There will be a global and a per-submodule configuration. But yes, if the
.git/config or .gitmodules don't specify anything for this submodule the
global config will kick in. And if that isn't set I imagine that porcelain
by default will recurse into populated submodules while plumbing won't.

* 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

For porcelain I tend to unify "all", "populated" and "respect": recurse
into all populated submodules unless configured otherwise ("all" seems
kind of superfluous, as I would respect the users choice not to populate
a submodule after the initial clone). But for plumbing a "respect" option
makes sense, using it could tell it to use the same defaults and config
that porcelain uses to make writing scripts easier.

* 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?

I think the same option that controls the cloning of submodules should
control whether a new submodule will be populated or not. For submodules
that already existed despite that it might be nice to remember and respect
the users choice and restore it if it existed before.


Maybe I'll have to mention the next steps not covered by my proposal:

2) Checkout submodules on clone

3) Move .git-Directories into the .git of the superproject (this will
   enable us to delete and recreate submodules without cloning again or
   loosing local branches and/or tags).


After thinking about it again I now tend to agree with Junio that we should
bring in the functionality without enabling it by default first and then
later decide if and to what we change the defaults. So I draw back this
proposal and will post it again when all three steps are implemented and can
be properly evaluated.

Thanks both for your feedback!