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

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

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? And so for each and every
checkout operation? I suggest you try checkout something like KDE a
few times (well, assuming KDE is split in submodules. It isn't yet).
The point is - it is annoying. And if it is annoying, it wont be used
(as branches in CVS and merging in SVN).

> > The more important issue I think is at what point in the
> > superproject operation does a recursive checkout in a subproject
> > should happen, and how we should do the checkout.  Issues I can
> > think of offhand are (no way exhaustive):
> > 
> >  - Do we checkout a branch? if so which one?
> > 
> >  - Do we detach HEAD if the commit named by the superproject
> >    tree is not at the tip of the current branch of subproject?
> >    do we detach always even if the commit is at the tip?
> 
> I thought there was a consensus to detach the HEAD.
> I don't have a strong opinion on this issue, but a detached
> HEAD seems the most appropriate to me.

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?!

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