Re: Newbie question regarding 3way merge order.

From: Sitaram Chamarty <sitaramc@gmail.com>
Date: Feb 2, 2009, 01:50 UTC
Message-ID: <slrngockbi.vsa.sitaramc@sitaramc.homelinux.net>
In-Reply-To: <7vskmyt127.fsf@gitster.siamese.dyndns.org>

On 2009-02-01, Junio C Hamano <gitster@pobox.com> wrote:

Show 9 quoted lines

> Sitaram Chamarty <sitaramc@gmail.com> writes:
>
>> Reversing A and B is one thing, applying a sequence of
>> merges in a different order is quite something else.
>
> This point is true in theory but I haven't found it to cause problems in
> practice.  Textual conflicts between topics do happen, but it does not
> happen so often in overlapping areas across more than two topics that
> earlier resolutions to them cannot be reused by the rerere mechanism.

[snip]

Show 9 quoted lines

> to force a merge order to the mainline can be used not only to deal with
> semantic conflicts but textual ones, too.  If two branches textually
> interact badly, you prepare a consolidated topic between the two, so that
> you can merge A alone, B alone, or A+B together to the mainline.
>
> 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.

Thanks; great explanation. I notice you blogged it too, and similar to the "Never merging back" post, the message is: if something is (or is likely to be) an independent feature, it should have its own branch and be merged into others as soon as it is known they need it. (In that post, it was a random crazy feature that one might normally dump into a customer branch, here it's a bugfix B that you might naively dump into feature A, but the basic logic is the same)