On Saturday 16 December 2006 23:58, Martin Waitz wrote: > > If the plumbing layer does not have to (although I haven't > > thought it through, it does feel like it even shouldn't) unwrap > > "link" and let the Porcelain layer to deal with it, that would > > certainly make rev-list/revision.c part simpler. > > Yes. However, it makes other things more complicated. > If the plumbing does not do all the subproject stuff and you don't have > everything in one database Even without plumbing doing the subproject stuff, we could use the same, unified database for the objects. Or do I miss something? As you said: the problem are submodule commit in superproject trees which are not reachable by refs of the submodule. However, we only need these commits when cloning/fetching the submodule in the scope of cloning/fetching the superproject; we simply can not use here a normal repository of the submodule, as these commits would be not available there. We should add a plumbing command for "Give me the minimal set of commits (from all submodules) which have all the submodule link object ids as ancestors which appear in the history of a given commit (from a superproject)". With this, building the set of objects to pack/fetch/clone into a unified object database for a superproject with its submodules should be easy. It is also needed for pruning the unified object database. Pruning in submodules simply would print out an error "Pruning in submodules not supported. Prune in the superproject instead". Josef - 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