git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Waitz <tali@admingilde.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alex Riesen <raa.lkml@gmail.com>, Junio C Hamano <junkio@cox.net>,
	git@vger.kernel.org
Subject: Re: [PATCH] submodule merge support
Date: Mon, 7 May 2007 11:03:46 +0200	[thread overview]
Message-ID: <20070507090346.GI30511@admingilde.org> (raw)
In-Reply-To: <alpine.LFD.0.98.0705061517380.12945@woody.linux-foundation.org>

[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]

hoi :)

On Sun, May 06, 2007 at 03:18:53PM -0700, Linus Torvalds wrote:
> On Mon, 7 May 2007, Alex Riesen wrote:
> > merge-recursive is a mess already, you just made even more so.
> > Besides, you completely forgot all other merge strategies.
> > 
> > How about making all existing strategies just ignore submodules, and
> > move recursive merge in the merge driver (git-merge.sh)?
> 
> Yes, I think that's the right thing to do.
> 
> I think it's the right thing for another reason: in a true "recursive" 
> merge, the submodules shouldn't be recursively merged anyway. *THEIR* 
> merge will have its own history, and doing it based on some random history 
> of the superproject is actually wrong anyway!

Of course the submodule has to get its own history, it's not possible
to do otherwise.  But you have to trigger the submodule merge when you
find a submodule-level conflict in the supermodule merge, just as
you trigger file-level three-way merges, too.
This is really all which my patch does -- it starts a new instance of
the merge driver which only merges the submodule commit from the other
supermodule tree.
So it's not recursive in the merge-recursive way, but in a
call-git-merge-again way.

The comment about merge-recursive not being the best place is correct of
course.

-- 
Martin Waitz

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-05-07  9:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-06 19:02 [PATCH] submodule merge support Martin Waitz
2007-05-06 22:07 ` Alex Riesen
2007-05-06 22:16   ` Martin Waitz
2007-05-06 22:18   ` Linus Torvalds
2007-05-07  9:03     ` Martin Waitz [this message]
2007-05-07 10:30       ` Johannes Sixt
2007-05-07 16:02         ` Linus Torvalds
2007-05-07 16:44           ` Martin Waitz
     [not found]             ` <alpine.LFD.0.98.0705070959060.3802@woody.linux-foundation.org>
     [not found]               ` <alpine.LFD.0.98.0705071015230.3802@woody.linux-foundation.org>
2007-05-07 19:33                 ` Martin Waitz
2007-05-07 16:37         ` Martin Waitz

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=20070507090346.GI30511@admingilde.org \
    --to=tali@admingilde.org \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=raa.lkml@gmail.com \
    --cc=torvalds@linux-foundation.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).