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

From: Martin Waitz <[email-masked]>
Date: Sun, 20 May 2007 23:40:26 +0200

hoi :)

On Sun, May 20, 2007 at 10:54:44PM +0200, Alex Riesen wrote:
> 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*.

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