Re: Submodule object store

From: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Date: Mar 27, 2007, 17:22 UTC
Message-ID: <20070327172216.GA24200@informatik.uni-freiburg.de>
In-Reply-To: <20070327155306.GQ22773@admingilde.org>

Hallali,

Martin Waitz wrote:

Show 13 quoted lines

> On Tue, Mar 27, 2007 at 01:50:29PM +0200, Uwe Kleine-König wrote:
> > If you separate the odbs e.g by the pathname of the subproject, what
> > happens if I choose to move the linux kernel in my embedded Linux
> > project from /linux to /kernel/linux?
> 
> Then a new separate object database would have to be created.
> This is the part I really don't like about separate object databases,
> but perhaps some persistent alternates information could help here.
> 
> For any other way to separate the odb (project id, whatever), we
> can't get a list of references into it by a path-limited traversal
> in the parent. Thus separate odbs which are not bound to a special
> location have some serious downsides.

(CVS comes to mind ...) This currently convinces me that a separate odb is wrong.

Show 6 quoted lines

> > Or maybe worse:  If I currently track the Kernel in a tree (because of
> > git lacking submodule support) and switch to submodule.  Then
> > linux/Makefile has to exist in both the supermodule's and the
> > submodule's odb.
> 
> Sorry, I don't understand you here.

Assume I have

	embeddedproject$ git ls-tree HEAD | grep linux
	040000 tree 0123456789abcdef... linux-2.6

and then I commit on top of that, s.t. I get:

	embeddedproject$ git ls-tree HEAD | grep linux
	040000 commit 0123456789abcde0... linux-2.6

(or how ever you save submodules). Then you might have to duplicate the objects of linux-2.6, because they are part of both histories.

Best regards Uwe

-- 
Uwe Kleine-König

primes where sieve (p:xs) = [ x | x<-xs, x `rem` p /= 0 ]; \
primes = map head (iterate sieve [2..])