Re: Notes on Using Git with Subprojects

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