Thread (23 messages) flat view 23 messages, 6 authors, 2016-06-15

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

From: Sven Verdoolaege <hidden>
Date: 2016-06-15 22:43:11

On Sun, May 20, 2007 at 10:54:44PM +0200, Alex Riesen wrote:
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?
I guess I'm missing something.
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.
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?

skimo
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help