From: "Raimund Berger" <raimund.berger@gmail•com>
To: git@vger•kernel.org
Subject: Re: Newbie question regarding 3way merge order.
Date: Mon, 02 Feb 2009 15:58:47 +0100 [thread overview]
Message-ID: <871vugc2c8.fsf@gigli.quasi.internal> (raw)
In-Reply-To: <7vskmyt127.fsf@gitster.siamese.dyndns.org> (Junio C. Hamano's message of "Sun, 01 Feb 2009 11:22:08 -0800")
Junio C Hamano <gitster@pobox•com> writes:
[snip]
> This is where you need to use the tool right to get the most out of it.
>
> You could do this in addition to (2).
>
> (3) Because B is an independent bug, you can have its own topic to fix it
> and merge it to the test integration, planning to merge it later to
> mainline independently from feature A topic. But you already know
> feature A depends on bugfix B to work correctly, so you merge the fix
> to the feature as well in advance.
>
> ---o-------*---* test integration branch
> / / /
> / / o bugfix B
> / / / \
> / o-------* feature A
> / / /
> o---o---o---o---o mainline
You seem to suggest that juggling merges is possible in the exact way I
was inquiring about. So let me ask again:
if M1 and M2 are merges and I define equality of merges (M1==M2) to be
- M1 resolves automatically (on the textual level) iff (if and only if)
M2 does
- if either resolves automatically, the tree produced by M1 is the same
as that of M2 (the tree SHAs are the same)
do the following conditions hold
(i) A+B == B+A for all commits A,B
(ii) (A+B)+C == A+(B+C) for all A,B,C
where "+" designates the standard git 3way merge?
[snip]
> If you end up merging A first and then want to merge B later (or the other
> way around, merge B and then A), and if the second merge to the mainline
> causes huge textual conflicts, you can instead merge the conslidated topic
> A+B to the mainline.
One could imagine (corporate) policies though which might try to map
organizational "entities" (tasks, teams, according responsibilities) to
branches. I.e. contexts where conflict resolution through merging might
not always be desired and they'd rather be sought on a branch, i.e. by
producing a commit on either branch which resolves a possible
conflict. That's why I asked how rebase compares to merge and whether
the merge machinery underlying the former is exactly the same. I seem to
understand by now though that it is not.
next prev parent reply other threads:[~2009-02-02 15:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-29 22:25 Newbie question regarding 3way merge order Raimund Berger
2009-01-30 11:37 ` Raimund Berger
2009-01-30 17:31 ` Sitaram Chamarty
2009-01-30 19:09 ` Raimund Berger
2009-01-31 0:32 ` Sitaram Chamarty
2009-01-31 13:26 ` Raimund Berger
2009-01-31 21:45 ` Nanako Shiraishi
2009-02-01 14:13 ` Raimund Berger
2009-02-01 19:22 ` Junio C Hamano
2009-02-02 1:50 ` Sitaram Chamarty
2009-02-02 14:58 ` Raimund Berger [this message]
2009-02-02 16:10 ` Johannes Sixt
2009-02-02 18:15 ` Raimund Berger
2009-02-03 7:21 ` Johannes Sixt
2009-01-31 0:57 ` Nanako Shiraishi
2009-01-31 13:14 ` Raimund Berger
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=871vugc2c8.fsf@gigli.quasi.internal \
--to=raimund.berger@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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