# git merge vs git commit 5 messages from 2008-09-09 to 2008-09-09. Participants: Russell King, Junio C Hamano, Miklos Vajna, Matthieu Moy. Thread: https://gitlist.dev/t/15452 ## Russell King, 2008-09-09 16:52 Subject: git merge vs git commit Message-ID: <20080909165236.GA8850@flint.arm.linux.org.uk> URL: https://gitlist.dev/e/20080909165236.GA8850%40flint.arm.linux.org.uk ``` 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 ``` ## Junio C Hamano, 2008-09-09 17:34 Subject: Re: git merge vs git commit Message-ID: <7vhc8p6x59.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vhc8p6x59.fsf%40gitster.siamese.dyndns.org In-Reply-To: <20080909165236.GA8850@flint.arm.linux.org.uk> ``` Russell King 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? ``` ## Miklos Vajna, 2008-09-09 18:54 Subject: Re: git merge vs git commit Message-ID: <20080909185418.GI4829@genesis.frugalware.org> URL: https://gitlist.dev/e/20080909185418.GI4829%40genesis.frugalware.org In-Reply-To: <7vhc8p6x59.fsf@gitster.siamese.dyndns.org> ``` On Tue, Sep 09, 2008 at 10:34:42AM -0700, Junio C Hamano 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). ``` ## Junio C Hamano, 2008-09-09 19:11 Subject: Re: git merge vs git commit Message-ID: <7vd4jd6snt.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vd4jd6snt.fsf%40gitster.siamese.dyndns.org In-Reply-To: <20080909185418.GI4829@genesis.frugalware.org> ``` Miklos Vajna writes: > On Tue, Sep 09, 2008 at 10:34:42AM -0700, Junio C Hamano 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. ``` ## Matthieu Moy, 2008-09-09 21:32 Subject: Re: git merge vs git commit Message-ID: URL: https://gitlist.dev/e/vpqiqt50zve.fsf%40bauges.imag.fr In-Reply-To: <20080909165236.GA8850@flint.arm.linux.org.uk> ``` Russell King 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 ```