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

[Marc Branchaud <marcnarc@xiplink.com>]

On 11-02-21 01:30 PM, Jens Lehmann wrote:
> 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 ;-)

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.

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

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

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