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

From: Martin Waitz <tali@admingilde.org>
Date: May 20, 2007, 21:40 UTC
Message-ID: <20070520214026.GL5412@admingilde.org>
In-Reply-To: <20070520205444.GC25462@steel.home>

hoi :)

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

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

right. except when you have some managed-by-superproject branch which is known to be special ;-)

After all the submodule checkout is independent from its parent repository, too -- so you don't screw anything *g*.

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.

sounds good. With submodules we have to consider one extra level of merging. -m in the supermodule also means that an automatic merge of the dirlink entry should be done. Which would execute git-merge in the submodule. And merging in a dirty tree is a challenge of its own.

So if local changes conflict with the checkout we should just error out.

-- 
Martin Waitz