Miklos Vajna wrote:
On Wed, Sep 17, 2008 at 10:11:02AM +0200, Jakub Narebski <jnareb@xxxxxxxxx> 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@xxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
