Re: git merge vs git commit

From: Ulrik Sverdrup <ulrik.sverdrup@gmail.com>
Date: Sep 10, 2008, 17:42 UTC
Message-ID: <a1b6cb1b0809101042x2d097524q7b95d4164141a443@mail.gmail.com>

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