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

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/