Re: [1.8.0] Recursively checkout, merge and reset populated submodules
- From
Marc Branchaud <marcnarc@xiplink.com>
- Date
- Feb 21, 2011, 19:56 UTC
- Message-ID
- <4D62C385.90204@xiplink.com>
- In-Reply-To
- <4D62AF46.8030508@web.de>
On 11-02-21 01:30 PM, Jens Lehmann wrote:
Show 18 quoted lines
> 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.
Show 30 quoted lines
>> * 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...
Show 9 quoted lines
>> * 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.