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

[David Kastrup <dak@gnu.org>]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Fri, 17 Aug 2007, David Kastrup wrote:
>> 
>> Now is there any chance to set up a git structure that will me
>> allow to let _git_ perform merges between the standalone dsp
>> project and the part that has started off as a copy of it in a
>> subdirectory from projects/great, so that I have a merge history in
>> my git mirror?
>
> Yes. That's what git "submodule" support is all about.  You could
> create that "dsp" project as its own git project, and then include
> it within the bigger project as a submodule. Then, that "dsp" thing
> is really a totally independent git project in its own right, with
> git support for just "tying" it into the superproject.

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".  There are
sometimes cross merges, but the stuff in the "dsp" subdirectory of
"great" is maintained completely together with the branches of
"great": tags, branches and all.

But I would like to be able to merge this _subdirectory_ with branches
from the "mothership" dsp from which it was originally copied.

With Subversion, I can actually merge files in different projects of
the repository even when they are in different directory levels.  Of
course, since Subversion does not track any merge info, that is not an
accomplishment.

I don't see quite how this would work with submodules, and in
particular not when git-svn gets involved as well.

> A few words of caution:
>
>  - while the low-level core submodule support has been around for a
>  while now, the actual "porcelain" level helper stuff is new to
>  1.5.3 (which is unreleased, so you'd have to use the current git
>  "master" branch, of course)

Have to for a variety of reasons, anyway.

>  - submodules are (very much by design) meant to be git projects in
>  their own right, and kept separate. That very explicit separation
>  means that you will *see* it as a separate project, and you may
>  decide that it's not worth the extra setup/complexity if the "dsp"
>  thing just isn't big enough or the merge complexity just isn't
>  worth the effort.

And that is the problem here: in this case it does not make sense to
see it as a separate project, and in particular, it needs to be in
synch with the tags/branches of the superproject, and particularly
while I am using git-svn.

> Another alternative is to do what git has long done with "gitk": you
> can maintain a separate project and just merge it directly into
> another git project, and it works fine that way, but it gets
> impossible to merge back and forth between the two projects (you can
> only merge one way: make all the major changes in the "dsp" project,
> and then you can just merge it into the project that uses it (but if
> you fix things in the bigger project, you can't merge the fixes
> back, you'll have to export the fixes as patches and do them in the
> "dsp" tree).

Well, that would be at least quite handy for propagating upstream dsp
fixes into project/great.  How do I merge one project into a
_subdirectory_ of another one?

-- 
David Kastrup