git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: git@vger.kernel.org
Subject: Re: How do I manage this setup with git-svn and/or git remotes?
Date: Sun, 19 Aug 2007 01:37:21 +0200	[thread overview]
Message-ID: <fa7vrd$afs$1@sea.gmane.org> (raw)
In-Reply-To: 86d4xmxbjf.fsf@lola.quinscape.zz

David Kastrup wrote:

> 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.

Independent git project means independent clone of "dsp" repository,
perhaps a fork of "dsp" repository with some (superproject) specific
commits. Which is attached as subritectory of superproject.
 
> But I would like to be able to merge this _subdirectory_ with branches
> from the "mothership" dsp from which it was originally copied.

You would be able to, both from "mothership" to "submodule", and from
"submodule" (perhaps only some selected commits on 'maint' branch) to
"mothership".

Putting files of "dsp" project directly in superproject and merging from
"mothership" using 'subtree' merge strategy as mentioned allows only for
one direction (well, except for sending patches).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

  parent reply	other threads:[~2007-08-18 23:37 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
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 [this message]
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='fa7vrd$afs$1@sea.gmane.org' \
    --to=jnareb@gmail.com \
    --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).