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

From: David Kastrup <dak@gnu.org>
Date: Aug 18, 2007, 07:07 UTC
Message-ID: <85643dwcb8.fsf@lola.goethe.zz>
In-Reply-To: <85mywpx2wl.fsf@lola.goethe.zz>

David Kastrup <dak@gnu.org> writes:

Show 23 quoted lines

> 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