Re: Submodule object store

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hallali,

Martin Waitz wrote:
> 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.

> > 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..])
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]