{"thread":{"id":"15452","subject":"git merge vs git commit","startedAt":"2008-09-09T16:52:37Z","lastAt":"2008-09-09T21:32:21Z","messageCount":5,"participants":["Russell King","Junio C Hamano","Miklos Vajna","Matthieu Moy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"90237","messageId":"20080909165236.GA8850@flint.arm.linux.org.uk","threadId":"15452","inReplyTo":null,"subject":"git merge vs git commit","fromName":"Russell King","fromEmail":"rmk@arm.linux.org.uk","sentAt":"2008-09-09T16:52:37Z","receivedAt":"2008-09-09T16:52:37Z","isPatch":false,"sender":{"key":"rmk@arm.linux.org.uk","avatar":null},"body":"Hi,\n\nUsing git 1.5.4.5, I notice that the result from git merge and git commit\nare different in an unexpected way.\n\nTake the following tree:\n\n B---C---D---E2\n /\n -A1\n \\\n F---G---H---I3\n\n(letters represent commits, numbers represent where the references are).\n\nYour current head is '1', and you want to merge branches '2' and '3', so\nyou use:\n\n\tgit merge 2 3\n\nIf there aren't any conflicts, you get a nice clean merge, resulting in:\n\n B---C---D---E2\n / \\\n -A J1\n \\ /\n F---G---H---I3\n\nHowever, if you have a conflict that needs resolving, you fix it up as\nnormal, and then use git commit. This results in:\n\n B---C---D---E2\n / \\\n -A---------------K1\n \\ /\n F---G---H---I3\n\ninstead - an additional reference from commit 'K' back to commit 'A'\nwhich isn't present in the clean merge case.\n\nIs this intentional, or is it a bug?\n\n-- \nRussell King\n"},{"id":"90240","messageId":"7vhc8p6x59.fsf@gitster.siamese.dyndns.org","threadId":"15452","inReplyTo":"20080909165236.GA8850@flint.arm.linux.org.uk","subject":"Re: git merge vs git commit","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-09-09T17:34:42Z","receivedAt":"2008-09-09T17:34:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Russell King writes:\n\n> If there aren't any conflicts, you get a nice clean merge, resulting in:\n> ...\n> However, if you have a conflict that needs resolving, you fix it up as\n> ...\n> instead - an additional reference from commit 'K' back to commit 'A'\n> which isn't present in the clean merge case.\n>\n> Is this intentional, or is it a bug?\n\nI think some changes went into 1.6.0 around this area to (r)eject parents\nthat are redundant. What happens when you use more recent git with the\nsame example?\n"},{"id":"90246","messageId":"20080909185418.GI4829@genesis.frugalware.org","threadId":"15452","inReplyTo":"7vhc8p6x59.fsf@gitster.siamese.dyndns.org","subject":"Re: git merge vs git commit","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-09-09T18:54:18Z","receivedAt":"2008-09-09T18:54:18Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Tue, Sep 09, 2008 at 10:34:42AM -0700, Junio C Hamano wrote:\n> I think some changes went into 1.6.0 around this area to (r)eject parents\n> that are redundant.\n\nYes, it was your 98cf9c3 (Introduce reduce_heads(), 2008-06-27).\n"},{"id":"90248","messageId":"7vd4jd6snt.fsf@gitster.siamese.dyndns.org","threadId":"15452","inReplyTo":"20080909185418.GI4829@genesis.frugalware.org","subject":"Re: git merge vs git commit","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-09-09T19:11:34Z","receivedAt":"2008-09-09T19:11:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Miklos Vajna writes:\n\n> On Tue, Sep 09, 2008 at 10:34:42AM -0700, Junio C Hamano wrote:\n>> I think some changes went into 1.6.0 around this area to (r)eject parents\n>> that are redundant.\n>\n> Yes, it was your 98cf9c3 (Introduce reduce_heads(), 2008-06-27).\n\nThat does not necessarily mean git-merge (or git-merge-octopus) uses that\nC function when coming up with the set of commits to record as parents.\n\nAs to what the correct behaviour is, I personally do not have a strong\npreference either way.\n\n - If you specify a fast-foward on the command line to merge into your\n HEAD, that is your choice and you may deserve the extra parent, even if\n it is redundant. \n\n - On the other hand, if you try to merge a single fast-forward, we do not\n even create a merge commit, so in the same spirit it may be better if\n we dropped the original HEAD from the merged result (i.e. Russell's\n \"cleanly merged\" case).\n\nI dunno.\n"},{"id":"90273","messageId":"vpqiqt50zve.fsf@bauges.imag.fr","threadId":"15452","inReplyTo":"20080909165236.GA8850@flint.arm.linux.org.uk","subject":"Re: git merge vs git commit","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2008-09-09T21:32:21Z","receivedAt":"2008-09-09T21:32:21Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Russell King writes:\n\n> Hi,\n>\n> Using git 1.5.4.5, I notice that the result from git merge and git commit\n> are different in an unexpected way.\n>\n> Take the following tree:\n>\n> B---C---D---E2\n> /\n> -A1\n> \\\n> F---G---H---I3\n>\n> (letters represent commits, numbers represent where the references are).\n>\n> Your current head is '1', and you want to merge branches '2' and '3', so\n> you use:\n>\n> \tgit merge 2 3\n\nAAUI, \"git merge 2 3\" doesn't mean \"merge 2 and 3 together\", but\n\"merge 2 and 3 with the current HEAD\". So, what you wanted was :\n\ngit checkout 1\ngit merge 2\n\nAnd what you did was an octopus merge of A, E and I (which ends up\nbeing the same since A is anyway the common ancestor of E and I).\n\nNow, this doesn't explain why the conflicted merge gives a result\ndifferent from the other.\n\n-- \nMatthieu\n"}]}