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

Am 21.02.2011 20:56, schrieb Marc Branchaud:

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

quoted

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

quoted

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.

quoted

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.

Yes. Upstream can give sane defaults but the user has the last word.

Sounds good to me!

Great to hear!