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

On 11-02-21 01:30 PM, Jens Lehmann wrote:

Am 21.02.2011 17:13, schrieb Marc Branchaud:

quoted

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 ;-)

Ooops, sorry for jumping the gun!  I figured that since clone normally does a
checkout that this would have to be worked out as part of the proposal.

quoted

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

quoted

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

quoted

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

A lot of what I'm confused about is how git would distinguish between 2 things:

 - How the user specifies submodule recursion within a local repo.

 - How a repo specifies initial submodule recursion for clones.

I'm happy to wait for your follow-up work to discuss this.  Cloning aside,
what you're proposing looks good to me.

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.

I haven't thought enough about plumbing to tell if it makes sense to
configure plumbing behavior explicitly.  But at first glance it seems odd...

quoted

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

So, .gitmodules initially controls recursion.  When a submodule gets
populated, it gets an entry in .git/config which then determines the
recursion behavior from then on.  Changing branches might change .gitmodules,
but anything in .git/config will persist so any customizations the user makes
will also persist.

Sounds good to me!

		M.