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

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

From: Alex Riesen <hidden>
Date: 2016-06-15 22:43:11

Sven Verdoolaege, Sun, May 20, 2007 21:59:30 +0200:
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? 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).
quoted
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?!
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help