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

David Kastrup [off-list ref] writes:

Junio C Hamano [off-list ref] writes:

quoted

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.

I think I got it.  My mistake was focusing all the time what I could
do with the git repository of "great" to facilitate two-way merges.

Instead I need to import great/trunk/dsp into a remote branch in my
_dsp_ git repository.  Since for git-svn, every Subversion directory
is as good to import as any other (there is no concept of a worktree
root in the repository) that should be all it takes.

I'll need to use the dsp repository when doing merge work, but apart
from that, I can work in the great repository r/w even while in the
dsp subdirectory.

If one could tell git in a remote section to
fetch/consider/synchronize/push just a subdirectory as the repo root,
then the same setup for bidirectional merges could be made to work
with projects like gitk.  Though I am fuzzy about the merge
information...  But that is a problem when pushing merges with private
branches, anyway, isn't it?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum