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

From: Alex Riesen <raa.lkml@gmail.com>
Date: May 20, 2007, 22:24 UTC
Message-ID: <20070520222410.GF25462@steel.home>
In-Reply-To: <20070520214026.GL5412@admingilde.org>

Martin Waitz, Sun, May 20, 2007 23:40:26 +0200:

Show 15 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.

But it is not a merge. It is a checkout. Being another operation it may even be disallow merges of subprojects. Just plainly tell user that this checkout is not possible because there are changes in subprojects and in the pointer to this subproject in the upper level superproject, and that the user should think about committing in subproject first.

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

On account of it being too complex. Always a good reason.