Working with remotes; cloning remote references

Hi all,

We're a Subversion shop moving to git, and our git-fu is still pretty weak. So I'd appreciate feedback on the setup I'm going to describe, in addition to the specific issue I'm going to raise.

Our products involve extensive customization of various externally-maintained code bases (mainly in FreeBSD, but also in a few other projects too). We'd like to track the various external repositories, to be able to bring their updates into our code base. We don't normally push our own customizations back upstream (yes, not The Way Things Should Be, please turn down the flamethrowers).

So we want our main code tree to be composed of our own code and an assortment of modified external code:

main/
   external1/
   external2/
   ourstuffA/
   ourstuffB/

Our general approach for supporting this (remember, git novices here) is to keep a local git mirror of each external code repository (say, with git-svn for the FreeBSD tree). Then we incorporate the local mirrors into our main repo, each under its own directory.

I've looked at two ways to do this: submodules and subtree merges, and the latter looks better to me. The main complication with submodules is branching and tagging. We need to branch or tag the entire main code tree, including all the external code bases. With submodules that seems like it would involve several steps to touch all the external mirror repos as well as the main repo. Another complication is that we do a lot of our work (50% or more) in the external code trees, and having to update the main repo's submodule references as that code changes seems rather fragile.

OTOH, a subtree merge nicely puts the external code into a specific spot in our main tree, lets that spot get updated with a single command (git pull -s subtree External2 master), and still let us branch and tag with single commands in the main repo. Also, the changes we make to externally-based code are plain old git pushes to the main repo. Clean and simple. (BTW, what does braid add beyond just doing subtree merges directly?)

So, first the general question: Anything braindead about the above? Any better ways to do this?

Now for the specific issue, which has to do with managing the remotes 
defined in the main repository.  The subtree-merge approach calls for 
the mirrored external repos to be "git remote add"-ed to the main repo. 
  But clones of that repo don't include the remote references (using git 
1.5.4.3 for my testing here).

I think that makes sense in most cases: Usually a developer will only want to clone the main repo and work with what's in there, ad not want to bother with the external references. But when it comes time to pull in updates from the external mirror repos the only place where that can be done is on the main repo where the original "git remote add" commands were issued.

That means merge work has to be done on the main repository's shared host (not good) and that testing merged code has to involve committing changes on the main shared repo (also not good, even in a branch) and testing them on a different host (still no goodness here).

 From this point of view (and please correct me if I'm wrong), it would 
be good if "git clone" had an option to include a repo's remote 
references in the clone.  The clone's origin reference would point to 
the original repo as usual, but all the other remotes would be in the clone.

Pushing and pulling would then also update (non-origin) the remote references.

Does this make sense? Am I missing something here? (And thanks for reading this far!)

		Marc