Re: [RFC] Third round of support for cloning submodules
- From
- Sven Verdoolaege <skimo@kotnet.org>
- Date
- May 20, 2007, 21:09 UTC
- Message-ID
- <20070520210954.GB942MdfPADPa@greensroom.kotnet.org>
- In-Reply-To
- <20070520205444.GC25462@steel.home>
On Sun, May 20, 2007 at 10:54:44PM +0200, Alex Riesen wrote:
Show 12 quoted lines
> 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? I guess I'm missing something.
Show 5 quoted lines
> 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.
Show 9 quoted lines
> > > - 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