Simplifying work across multiple projects (while tracking relationships among commit histories)

[Yang Zhang <yanghatespam@gmail.com>]

After looking at some of the tools/techniques out there for working
with multiple git projects (submodules, subtree merge, braid, repo),
it seems that none are really well-suited for our use case. We're
developing a large system consisting of several components (libraries,
servers, applications, etc.). None of these components will ever exist
or be released as a stand-alone product. We're in "rapid development"
mode, so we're not even close to dealing with e.g. manually
maintaining information on versions/dependencies, and we just want
very tight integration among all the components -- yet the components
do deserve their own disentangled histories and (eventually)
independent branches/tags/versions/etc.

If we were using svn, all the code would live in a single repository,
and that would be all there was to think about this. However, it seems
that our use case (surprisingly) doesn't have a lot of good support in
the DVCS world.

For now, we'll probably just have some simple scripts that basically
do 'for i in $projects' loops for pulls, pushes, commits, etc.
However, this loses a lot of information that should be tracked about
the version/dependency information among the projects -- information
that at the same time we're not interested in manually tracking. We're
currently thinking of having a simple system that is initially set up
with a dependency graph among projects, e.g.:

  a: no dependencies
  b: depends on a

and whenever a commit is made to a project with dependencies (b), the
commit (perhaps in the commit message) contains a reference to the
particular versions of the dependent project(s) (a) that were checked
out.

The tool could simplify the use of such a scheme, e.g.:

- automatically augmenting commit messages with this information
- on commits/pushes, first commit/push the dependent projects
- checking out consistent versions of all the projects (or subgraphs thereof)

Does this make sense to others? Are we overlooking a better/existing
approach? Would it be worth building this? Suggestions on design
improvements to such a tool over what was described (e.g. better
approach than augmenting commit messages)?
--
Yang Zhang
http://yz.mit.edu/