David Kastrup <dak@xxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
