Re: Notes on Using Git with Subprojects

From: A Large Angry SCM <gitzilla@gmail.com>
Date: Sep 26, 2006, 22:01 UTC
Message-ID: <4519A321.4010507@gmail.com>
In-Reply-To: <Pine.LNX.4.63.0609262203510.25371@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin wrote:

Show 7 quoted lines

> Hi,
> 
> On Tue, 26 Sep 2006, A Large Angry SCM wrote:
> 
>> 							20060926.1715
> 
> You forgot the time zone ;-)

UTC of course. ;-)

[...]

Show 8 quoted lines

> 
> 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.

Since each project can have subprojects, the root project is special _only_ in that the initial checkout is _not_ handled by the build machinery (make in my example). This means that adding and removing subprojects should be no different for the root project. A subproject should be able to stand on its own (with its subprojects); otherwise, it's not a project but instead a directory tree versioned separately.

> 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.

Which I though was awful. Subprojects are really much better managed by the build machinery; it's more flexible and doesn't require all the separate projects to use the same VCS.

> Of course, the difficult thing about this is to teach all tools to behave 
> sensibly with the new object type.

And teach all the tools to gracefully handle subprojects using a different VCS ...

Show 19 quoted lines

> 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.

How the state (subproject list, branch names, etc.) is recorded in a parent project is only important to the parent project. The parent project must also know how to interact with with each of its subprojects.

For instance, if you were building some kind of internet appliance, it could have a very large number of subprojects (kernel, various servers and daemons, etc) with no common build tool or target set used by all of them. What each parent project does in this situation is to "interface" to the build machinery of each subproject so that when you command "make appliance image" at the top level project, all the subprojects _and_ the top level project do what is need to create the appliance image. The appliance can depend on projects using many VCS'; Git for the kernel, SVN for the web server, CVS for the SMTP daemon, Monotone for some other part, 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".

For _full_ subproject support, handling a tree of projects is required. So treating the root project differently that any other parent project (except of the initial checkout of the root project), means that you can't work a subproject independent of its parent projects.