From: "Daniel Bratell" <bratell@opera.com>
To: "Heiko Voigt" <hvoigt@hvoigt.net>
Cc: git@vger.kernel.org, "Jens Lehmann" <jens.lehmann@web.de>
Subject: Re: Merging submodules - best merge-base
Date: Thu, 07 Mar 2013 10:49:09 +0100 [thread overview]
Message-ID: <op.wtklj7e9rbppqq@cicero.linkoping.osa> (raw)
In-Reply-To: <20130306181156.GA4114@sandbox-ub>
Den 2013-03-06 19:12:05 skrev Heiko Voigt <hvoigt@hvoigt.net>:
> On Mon, Feb 25, 2013 at 05:44:05PM +0100, Daniel Bratell wrote:
>> I can phrase this in two ways and I'll start with the short way:
>>
>> Why does a merge of a git submodule use as merge-base the commit that
>> was
>> active in the merge-base of the parent repo, rather than the merge-base
>> of
>> the two commits that are being merged?
>>
>> The long question is:
>>
>> A submodule change can be merged, but only if the merge is a
>> "fast-forward" which I think is a fair demand, but currently it checks
>> if
>> it's a fast-forward from a commit that might not be very interesting
>> anymore.
>>
>> If two branches A and B split at a point when they used submodule commit
>> S1 (based on S), and both then switched to S2 (also based on S) and B
>> then
>> switched to S21, then it's today not possible to merge B into A, despite
>> S21 being a descendant of S2 and you get a conflict and this warning:
>>
>> warning: Failed to merge submodule S (commits don't follow merge-base)
>>
>> (attempt at ASCII gfx:
>>
>> Submodule tree:
>>
>> S ---- S1
>> \
>> \ - S2 -- S21
>>
>> Main tree:
>>
>> A' (uses S1) --- A (uses S2)
>> \
>> \ --- B' (uses S2) -- B (uses S21)
>>
>>
>> I would like it to end up as:
>>
>> A' (uses S1) --- A (uses S2) ------------ A+ (uses S21)
>> \ /
>> \ --- B' (uses S2) -- B (uses S21)- /
>>
>> And that should be legal since S21 is a descendant of S2.
>
> So to summarize what you are requesting: You want a submodule merge be
> two way in the view of the superproject and calculate the merge base
> in the submodule from the two commits that are going to be merged?
>
> It currently sounds logical but I have to think about it further and
> whether that might break other use cases.
Maybe both could be legal even. The current code can't be all wrong, and
this case also seems to be straightforward.
/Daniel
next prev parent reply other threads:[~2013-03-07 9:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-25 16:44 Merging submodules - best merge-base Daniel Bratell
2013-03-06 18:12 ` Heiko Voigt
2013-03-07 9:49 ` Daniel Bratell [this message]
2013-03-07 18:59 ` Heiko Voigt
2013-03-09 17:45 ` Jens Lehmann
2013-03-10 17:09 ` Heiko Voigt
2013-03-11 20:30 ` [RFC/PATCH] submodule: allow common rewind when merging submodules Heiko Voigt
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=op.wtklj7e9rbppqq@cicero.linkoping.osa \
--to=bratell@opera.com \
--cc=git@vger.kernel.org \
--cc=hvoigt@hvoigt.net \
--cc=jens.lehmann@web.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.