On Friday 2006, December 01 19:38, Martin Waitz wrote: > On Fri, Dec 01, 2006 at 07:17:17PM +0000, Andy Parkins wrote: > > In fact, why should the submodule commits be even visible in the > > supermodule? That tree->submodule commit is sufficient; there isn't > > any need to view submodule history in the supermodule. > > Well, but there is a need for a common object traversal. > You need that when sending all objects between two supermodule versions > and also when you determine which objects are still reachable. No you don't; when traversing the supermodule history you will come across trees that have submodule commit hashes in them, that is all the other end needs to know. If it wants it can then connect to the submodule and clone submodule to submodule. The whole operation doesn't have to be done in the supermodule though. > The easiest way to implement the common object traversal is to have all > objects in one object repository. That's true; but is it the right way? I really really think the submodule objects should be in the submodule itself. > It may be possible to use two object stores and still do the common > object traversal but I do not think that gives you any benefits. There is one benefit - you can git-clone the submodule just as you would if it were not a submodule. In fact, from the submodule's point of view it knows nothing about the supermodule. > You still don't have a totally separated repository then, because > you can't do a reachability analysis in the submodule repository alone. I'm going to guess by reachability analysis, you mean that the submodule doesn't know that some of it's commits are referenced by the supermodule. As I suggested elsewhere in the thread, that's easily fixed by making a refs/supermodule/commitXXXX file for each supermodule commit that references as particular submodule commit. Then you can git-prune, git-fsck whenever you want. Andy -- Dr Andrew Parkins, M Eng (Hons), AMIEE 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