David Kastrup <dak@gnu.org> writes:

quoted text
> Junio C Hamano <gitster@pobox.com> writes:
>>
>> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html