From: Linus Torvalds <torvalds@linux-foundation.org>
To: David Kastrup <dak@gnu.org>
Cc: git@vger.kernel.org
Subject: Re: How do I manage this setup with git-svn and/or git remotes?
Date: Fri, 17 Aug 2007 10:56:25 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.0.999.0708171042570.30176@woody.linux-foundation.org> (raw)
In-Reply-To: <86y7gaxef5.fsf@lola.quinscape.zz>
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.
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)
- 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.
- not very many people use it. The msysgit people seem to be using it,
and Andy Parkins has been using it for a while (and seems happy), but I
think you basically end up having less documentation and somewhat less
support for it (and it doesn't get the same kind of testing that the
"basic" git behaviours get).
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).
Linus
next prev parent reply other threads:[~2007-08-17 17:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-17 17:24 How do I manage this setup with git-svn and/or git remotes? David Kastrup
2007-08-17 17:56 ` Linus Torvalds [this message]
2007-08-17 18:26 ` David Kastrup
2007-08-17 18:53 ` Linus Torvalds
2007-08-17 21:04 ` David Kastrup
2007-08-17 21:18 ` Junio C Hamano
2007-08-17 21:32 ` David Kastrup
2007-08-18 7:07 ` David Kastrup
2007-08-18 23:37 ` Jakub Narebski
2007-08-19 16:04 ` David Kastrup
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.0.999.0708171042570.30176@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=dak@gnu.org \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).