Matthieu Moy <Matthieu.Moy@imag.fr>:
Show 35 quoted lines
> >>Russell King <rmk@arm.linux.org.uk> writes: >> >> Hi, >> >> Using git 1.5.4.5, I notice that the result from git merge and git commit >> are different in an unexpected way. >> >> Take the following tree: >> >> B---C---D---E2 >> / >> -A1 >> \ >> F---G---H---I3 >> >> (letters represent commits, numbers represent where the references are). >> >> Your current head is '1', and you want to merge branches '2' and '3', so >> you use: >> >> git merge 2 3 > >AAUI, "git merge 2 3" doesn't mean "merge 2 and 3 together", but >"merge 2 and 3 with the current HEAD". So, what you wanted was : > >git checkout 1 >git merge 2 > >And what you did was an octopus merge of A, E and I (which ends up >being the same since A is anyway the common ancestor of E and I). > >Now, this doesn't explain why the conflicted merge gives a result >different from the other. >
(I'm not on the list, please CC)
Reading the whole thread I think we have an explanation: octupus-merge learned to remove reduntant parents and does so in the clean merge case, but merge in general does not it; this is what happens in the conflict case.
However it remains that three parents are to be expected with the given user action
Ulrik Sverdrup