git merge vs git commit

git merge vs git commit

[Russell King]

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

If there aren't any conflicts, you get a nice clean merge, resulting in:

     B---C---D---E2
    /             \
  -A               J1
    \             /
     F---G---H---I3

However, if you have a conflict that needs resolving, you fix it up as
normal, and then use git commit.  This results in:

     B---C---D---E2
    /             \
  -A---------------K1
    \             /
     F---G---H---I3

instead - an additional reference from commit 'K' back to commit 'A'
which isn't present in the clean merge case.

Is this intentional, or is it a bug?

-- 
Russell King

Re: git merge vs git commit

[Junio C Hamano]

Russell King <rmk@arm.linux.org.uk> writes:

> If there aren't any conflicts, you get a nice clean merge, resulting in:
> ...
> However, if you have a conflict that needs resolving, you fix it up as
> ...
> instead - an additional reference from commit 'K' back to commit 'A'
> which isn't present in the clean merge case.
>
> Is this intentional, or is it a bug?

I think some changes went into 1.6.0 around this area to (r)eject parents
that are redundant.  What happens when you use more recent git with the
same example?

Re: git merge vs git commit

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 248 bytes --]

On Tue, Sep 09, 2008 at 10:34:42AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> I think some changes went into 1.6.0 around this area to (r)eject parents
> that are redundant.

Yes, it was your 98cf9c3 (Introduce reduce_heads(), 2008-06-27).

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: git merge vs git commit

[Junio C Hamano]

Miklos Vajna <vmiklos@frugalware.org> writes:

> On Tue, Sep 09, 2008 at 10:34:42AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
>> I think some changes went into 1.6.0 around this area to (r)eject parents
>> that are redundant.
>
> Yes, it was your 98cf9c3 (Introduce reduce_heads(), 2008-06-27).

That does not necessarily mean git-merge (or git-merge-octopus) uses that
C function when coming up with the set of commits to record as parents.

As to what the correct behaviour is, I personally do not have a strong
preference either way.

 - If you specify a fast-foward on the command line to merge into your
   HEAD, that is your choice and you may deserve the extra parent, even if
   it is redundant.  

 - On the other hand, if you try to merge a single fast-forward, we do not
   even create a merge commit, so in the same spirit it may be better if
   we dropped the original HEAD from the merged result (i.e. Russell's
   "cleanly merged" case).

I dunno.

Re: git merge vs git commit

[Matthieu Moy]

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.

-- 
Matthieu

Re: git merge vs git commit

[Ulrik Sverdrup]

Matthieu Moy <Matthieu.Moy@imag.fr>:
>
>>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