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

Sven Verdoolaege, Sun, May 20, 2007 23:09:54 +0200:

On Sun, May 20, 2007 at 10:54:44PM +0200, Alex Riesen wrote:

quoted

Sven Verdoolaege, Sun, May 20, 2007 21:59:30 +0200:

quoted

quoted

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.

quoted

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?

quoted

quoted

quoted

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