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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
