Re: [1.8.0] Recursively checkout, merge and reset populated submodules
- From
Jens Lehmann <jens.lehmann@web.de>
- Date
- Feb 21, 2011, 22:54 UTC
- Message-ID
- <4D62ED38.7070408@web.de>
- In-Reply-To
- <4D62C385.90204@xiplink.com>
Am 21.02.2011 20:56, schrieb Marc Branchaud:
Show 10 quoted lines
> On 11-02-21 01:30 PM, Jens Lehmann wrote: >> Am 21.02.2011 17:13, schrieb Marc Branchaud: > 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.
Cool. When I'm done with the local repo stuff I'll continue working on the cloning part, so stay tuned for further discussions on that topic :-)
Show 6 quoted lines
>> 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...
Plumbing shouldn't care about user config by default because the aim is to have predictable behavior. But e.g. git gui, which is using plumbing under the hood to do the actual checkout, should honor user configuration and porcelain defaults (because it is percieved by the user as being porcelain itself). So git gui would benefit from being able to simply tell plumbing "behave like you were porcelain" through an option instead of coding recursion, user configuration and the safety checks needed before checkout itself. And this would avoid code duplication too.
Show 15 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.
Yes. Upstream can give sane defaults but the user has the last word.
> Sounds good to me!
Great to hear!