Re: How do I manage this setup with git-svn and/or git remotes?

Junio C Hamano [off-list ref] writes:

Linus Torvalds [off-list ref] writes:

quoted

On Fri, 17 Aug 2007, David Kastrup wrote:

quoted

But it isn't an independent git project: the superproject has its
_own_ copy of dsp, with its _own_ specific commits and fixes that are
not supposed to ever end up in the dsp "mothership". 

Sure. And that's different from any git "branch" exactly how?

So you'd have different branches in the superproject - the way you always 
have when you have two copies of a git project. And then you merge between 
the two at will.

My reading of the project David is talking about is that its dsp
project which is a "subproject" part gets non generic commits within
the context of the superproject --- which means (1) you would have
branches in the subproject not superproject, and (2) once you did
that, the subproject is not really a subproject anymore, as you
cannot merge that back to the standalone dsp project without
dragging the non-generic bits along with it.

Ok, I should perhaps should not make things harder than they are: the
superprojects, being particular to one customer each, don't really
branch (except that git-svn makes a git branch from every Subversion
tag).  The subproject is the one that has considerable branching and
merges.  What usually gets pulled into the superproject is a copy of a
stable subproject branch.  Once this copy is in, only fixes (from the
stable branch) or features (from the development branch) that the
customer definitely needs are merged into the superproject.  While
there might happen some subproject work in the customer branch, this
mostly happens during bugfixing for the customer, and the changes are
typically pulled back into the subproject proper at some point of
time.  Inside of the subproject tree, there is really no superproject
_development_ going on.

quoted

There's a special "subtree" merge that does exactly that: it
basically is the normal recursive merge, except it merges into a
subtree. I think that's how Junio does the "git-gui" merges. Junio?

Yes.  It has exactly the same semantics and limitations with the
gitk merge, but just merges into a sub directory.  Shawn cannot
easily pull the changes done inside git.git repository back to
git-gui.git proper.

Well, the other direction would be the most important one: merging or
cherrypicking selected changes in the subproject branches into the
superproject copy of the subproject.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum