Subject: Working with remotes; cloning remote references

From: Marc Branchaud <[email-masked]>
Date: Thu, 16 Oct 2008 14:17:19 -0400

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