On Friday 2006 December 01 12:28, Martin Waitz wrote:
> > 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
andyparkins@xxxxxxxxx
-
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