Re: Newbie question regarding 3way merge order.

Nanako Shiraishi [off-list ref] writes:

Quoting "Raimund Berger" [off-list ref] writes:

quoted

I'm myself, especially since a conflicting rebase leaves the index in an
"unmerged" state. Much like a regular merge does. It's still all
assumptions though, or maybe I'm missing documentation .... (?)

The rebase command you run with neither -m nor -i option replays
your work on top of the upstream by running git-am with the --3way
option.

This commit introduced the feature.

commit 7f59dbbb8f8d479c1d31453eac06ec765436a780
Author: Junio C Hamano [off-list ref]
Date:   Mon Nov 14 00:41:53 2005 -0800

    Rewrite rebase to use git-format-patch piped to git-am.
    
    The current rebase implementation finds commits in our tree but
    not in the upstream tree using git-cherry, and tries to apply
    them using git-cherry-pick (i.e. always use 3-way) one by one.
    
    Which is fine, but when some of the changes do not apply
    cleanly, it punts, and punts badly.

    [omitting the rest]

The message talks about what was wrong with the original, what
benefit it gives the users, and how to use it, but it doesn't
discuss how the magic works in detail.

Junio much later describes how it works, taking a real-world example
in this message:

http://thread.gmane.org/gmane.comp.version-control.git/46569/focus=46609

In short, it works by applying your changes as patches but when a
patch doesn't apply it falls back to a simplified three-way merge.

http://thread.gmane.org/gmane.comp.version-control.git/100579/focus=100602

I think Junio misremembered the history in his last message in the thread.
He says that rebase was originally a format-patch piped to am, but
before the commit 7f59dbbb8f8d479c1d31453eac06ec765436a780 it was
done by a series of cherry-pick.

Ugh. OK, that really explains a lot alright. Especially that fundamental
change in rebase behavior makes it quite clear that the various
techniques for "merging" content might not be as consistent as I had
hoped. In my ideal world they'd only differ in how they map out commit
history, but obviously that's not the case.

To me, this really leaves questions open regarding a hassle free
workflow. Since one apparently can't be confident that conflict
resolutions obtained in some testing or early integration branch will
easily carry over to stable it looks like special measures need to be
taken, like strict observation of merge order/technique and employment
of replay tools.

So serialization apparently can't entirely be lost, and where e.g. CVS
kind of enforces it at an early stage through expensive branching it
seems git still requires some of the same coordination just at a
different level resp. point in time.

Hey, thanks a bunch for taking the time carrying those links
together. They've been very informative.