Hi, On Tue, 26 Sep 2006, A Large Angry SCM wrote: > 20060926.1715 You forgot the time zone ;-) > Notes on Using Git with Subprojects > =================================== > Copyright (C) 2006 by Raymond S Brand > > > Git does not have native support for subprojects and this is a good > thing because managing subprojects is better handled by the project > build machinery. Managing subprojects with the project build machinery > is more flexible than the native support from an SCM and allows the use > of different SCMs by different subprojects. However, there is a lot of > interest in using Git for the SCM of a project with subprojects. > > Git, unfortunately, does not make it easy. After skimming your text, I imagine that it should be possible (read: easy) to write a really simple script which does what you describe, storing the relevant information about root or sub projects in the config. However, you left out one of the most important aspects of subprojects: the ability to manage the state of the root project: you can add, update and remove subprojects. A while ago, Junio started playing with a new object type for subprojects so that you could have tree objects containing subprojects in addition to tree objects and blobs. Of course, the difficult thing about this is to teach all tools to behave sensibly with the new object type. Now, your approach of having multiple clones (sharing the object pool) is more simple than Junio's approach: no need to introduce a new object type, or adapt existing tools. Taking this a step further, how about managing the root project in this manner: A root project is a branch containing just one special file, "root-project". This file consists of lines like these: -- snip -- f80a17bf3da1e24ac904f9078f68c3bf935ff250 next 03adf42c988195b50e1a1935ba5fcbc39b2b029b todo -- snap -- The meaning: subdirectory "next" contains subproject "next" which is also tracked in the branch "next" of the root project. Likewise for "todo". The root project could even contain some administrative files like a Makefile, a license, README, etc. You could even handle the update of root-project with each commit in a subproject by a hook in that subproject's .git/hooks/post-commit, so that you'd only need a script "git-checkout-root-project.sh" to initialize them all, and probably a script "git-update-root-project.sh". Thoughts? Ciao, Dscho P.S.: Is it just me, or do other people also find it confusing that --shared means different things for git-init-db and git-clone? (I know I am the sinner...) - 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