Miklos Vajna wrote:
quoted text
> On Wed, Sep 17, 2008 at 10:11:02AM +0200, Jakub Narebski <jnareb@gmail.com> wrote:
>>>> BTW. does it mean that "git merge a b" might be not the same as
>>>> "git merge b a"?
>>>>
>>> No. Git merges all the sub-things together and then merges the result
>>> of that jumble into the branch you're on.
>>>
>>> Someone might have to correct me on that, but that's as far as I've
>>> understood it.
>> From what I understand from above explanation, and from thread on git
>> mailing list about better implementation of and documenting finding
>> merge bases for multiple heads, I think octopus merge is done by merging
>> [reduced] heads one by one into given branch.
>>
>> This means that "git merge a b" does internally "git merge a; git merge b"
>> as I understand it.
> 
> Sure, but given that both 'a' and 'b' merged (so none of them is subset
> of the other, for example so that reduce_heads() would drop one of them)
> the order of the parents will be different so the resulting commit will
> differ. The resulting tree will no, I think.


I got it wrong (not wrt reduced heads, but still). My apologies.

If octopus (the program/strategy/whatever) continues to merge after a
branch conflicting against the currently checked out branch (let's call
it "master"), the resulting tree may not differ, but then again, it might.
OTOH, if octopus quits the merge after having encountered a conflict, the
order the branches to merge were passed will always have an impact.

Let's say you have two branches, "clean" and "conflict". Which one is
which should be obvious here.

	git merge clean conflict

will produce a tree with 'master', 'clean' and a conflicted merge of
'conflict', while

	git merge conflict clean

will produce a tree with 'master' and a conflicted merge of 'conflict'.

In short, backing out the entire merge in case of a conflict is almost
certainly the only sane thing to do. If one branch depends on another
to merge cleanly, a different approach should have been taken (depending
branch should have been rebased onto the dependent one prior to merging),
but the merge *might* succeed depending on in which order the other
branches are given as arguments. It's not a very clever idea to merge
something like that though, as bisection will invariably have to mark the
entire depending branch as BAD, although the merge itself could obviously
be a good one.

Clearly, an octopus merge should not be undertaken without knowing very
well what it is one is merging in.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html