Re: [RFC] Submodules in GIT
- From
- Andy Parkins <andyparkins@gmail.com>
- Date
- Dec 1, 2006, 14:11 UTC
- Message-ID
- <200612011411.20113.andyparkins@gmail.com>
- In-Reply-To
- <20061201122854.GR18810@admingilde.org>
On Friday 2006 December 01 12:28, Martin Waitz wrote:
Show 5 quoted lines
> > It seems wrong because it's making commits in the supermodule that aren't > > commits to do with that project. > > Of course they are part of your project, just like all the tree and blob > objects, too.
I wouldn't go as far as that; just because I use libxcb doesn't mean I want it's history merged with mine. However, I think my worries are unfounded, your comment about being able to independently clone the libxcb tree helped me there. If I've understood; while the objects themselves are stored in the supermodule ODB, they are still independent. In fact, they're only in the supermodule tree because it's most convenient to keep them there; it sounds like it's very easy to strip them out again.
> It is the commit of the submodule, so its parents point to the submodule > history.
Again, if I'm understanding, it's a bit like when you have an additional root
in a normal git repository, for example:
* -- * -- * -- * (project1)
\
* -- * -- * (project1/stable)
* -- * -- * -- * (project2)Then to make project2 a submodule of project1, one of the project1 trees simply refers to a commit in project2.
I think my original idea for how this works was correct with one minor flaw, and from that flaw all the other concerns flowed. I imagined that there were two object databases - one for the supermodule and one for the submodule. The fault was that there aren't two ODBs there are two roots. Which of course is a far easier way to blend to repositories. Apart from that, I think I'm entirely in sync, and it was merely my wanting to put each of these roots in their own repository that caused all the confusion.
Andy
-- Dr Andy Parkins, M Eng (hons), MIEE