Re: [RFC] Third round of support for cloning submodules

[Alex Riesen <raa.lkml@gmail.com>]

Sven Verdoolaege, Sun, May 20, 2007 23:09:54 +0200:
> On Sun, May 20, 2007 at 10:54:44PM +0200, Alex Riesen wrote:
> > Sven Verdoolaege, Sun, May 20, 2007 21:59:30 +0200:
> > > > I am very worried about this big red switch that says "all
> > > > subprojects to be cloned and checked out, or nothing".  I think
> > > > this would not work well with projects that truly need
> > > > superproject support (i.e. very large ones, where most people
> > > > would not want to clone and check out every single subproject).
> > > 
> > > It's pretty easy to add a "submodule.*.skip" or "submodule.*.ignore".
> > > Since the subcloning only happens at checkout, you could set these
> > > before doing a checkout.
> > 
> > And set them back after doing the checkout?
> 
> What do you mean?  Why would you set them back?

Why should I set them before doing a checkout?

> I guess I'm missing something.

"checkout" is an operation which is done often. It never had to be
configured before.

> > Me too. I actually believe it is the only way to do it. How can you
> > checkout a subproject to something else (to what a branch may point)
> > and to what the tree of superproject has? On the other side (in
> > subproject) - why are you, the superproject, allowed to screw the
> > references of the subproject?! It is independent, isn't it?!
> 
> Well... the subproject as a whole is independent of the superproject,
> but the checkout in the superproject is not entirely independent.
>

Junio was talking about branch in subproject, wasn't he?

> > > >  - What would we do when the subproject working tree is not
> > > >    clean?
> > > 
> > > I was planning on adding a --dry-run to git-checkout.
> > > The superproject would run this in each subproject before
> > > doing the actual checkout of the superproject.
> > 
> > Why not do exactly what we do now? Pass "-m" down to it, if it was
> > given to the top-level git-checkout.
> 
> We want to be sure that all (selected) subprojects can be updated before
> updating any, no?
> 

I guess passing "-m" to git-checkout _is_ an explicit permission from
the operator to perform a merge. Besides, it's visible: merge prints
something, user sees the "-m" in command history (or in script code).
Calling git-checkout twice even if we don't have to... it is kind of
ugly. Still need some dry-run this for normal case (checkout can be
modified to do this by default, I think).