git merge vs git commit

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 <rmk@arm.linux.org.uk> writes:

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?

On Tue, Sep 09, 2008 at 10:34:42AM -0700, Junio C Hamano <gitster@pobox.com> wrote:

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

Miklos Vajna <vmiklos@frugalware.org> writes:

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.

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

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.