On Wed, Sep 27, 2006 at 09:58:43AM -0700, A Large Angry SCM wrote: > This means that modules are not separate, stand alone projects but, > rather, just a sub part of your bigger project. Very useful and > applicable in some situations but other situations want/need separate, > stand alone subprojects. One thing that I believe some people have requested for subprojects is to avoid downloading files/history for subprojects you're not interested in. I think this could be faciliated in this scheme by only cloning the heads of the subprojects you're interested in (there would need to be special machinery to handle this at the root level if we want to allow making root commits without necessarily having all of the subprojects). A first step to this would be an argument to git-clone to allow cloning only a subset of refs. > The problem I'm working on is how to deal with the sub parts of a larger > project when those sub parts are controlled by different entity. Silly > example: the kernel is controlled by Linus; glibc is controlled by the > GNU folks, gcc is controlled by some other GNU folks, the web server is > controlled by the Apache Foundation, the X server is controlled by Xorg, > etc. The nice thing about this approach is that I believe the two systems need only differ at clone time. Instead of creating a remotes file with all of the subproject branches, you would just create multiple remotes files. The root fetching porcelain needs to be smart enough to fetch all remotes. -Peff - 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