question on merges

question on merges

[Lennert Buytenhek]

Hi,

If a git user has X as his most recent local commit, and merges in a
commit Y from someone else to create commit Z, shouldn't commit Z have
both commit X and Y as parents?  Or is is the other way round and is it
perfectly well possible that a 'merge commit' only has one parent?

In the current linux-2.6 git tree, gregkh clones torvalds'
7f907d7486f2519c2ff1493bfbcdc36dcacd85b7 and creates a chain of commits
starting with ac21e9ff08db3d6fac41d356c77fcb531c2e03e1 and ending in
e838a0d4d5260bce452c96914a6e86b217c53c55.  torvalds merges this chain
back into his version in a9e4820c4c170b3df0d2185f7b4130b0b2daed2c, but
that commit has as parents e838a0d4d5260bce452c96914a6e86b217c53c55
(gregkh's last commit), and c0698f2f6e4839ce9463ce731c892993215ea067,
one of jejb's intermediate commits.  But now why is
7f907d7486f2519c2ff1493bfbcdc36dcacd85b7 not a parent of
a9e4820c4c170b3df0d2185f7b4130b0b2daed2c?  I would expect it to be,
since it is linus' most recent local commit when he merges in gregkh's
tree.

This pattern happens a few more times:
- davem creates c4d541106bc5d0a2134aaf9e8735eee3c70b0db2 from torvalds'
  561bbe3235da614562fb26bb14042af684971a2d, and torvalds merges davem's
  tree back in at a2755a80f40e5794ddc20e00f781af9d6320fafb (v2.6.12-rc3),
  but that commit only has one parent (even though it's a merge.)

See this image:
	http://www.liacs.nl/~buytenh/graph_2cacb3da620a4a93f3a77e1d2c8c06bb3c74bcb0.png


cheers,
Lennert

Re: question on merges

[Sean]

On Mon, May 2, 2005 11:12 am, Lennert Buytenhek said:
> Hi,
>
> If a git user has X as his most recent local commit, and merges in a
> commit Y from someone else to create commit Z, shouldn't commit Z have
> both commit X and Y as parents?  Or is is the other way round and is it
> perfectly well possible that a 'merge commit' only has one parent?
>
> In the current linux-2.6 git tree, gregkh clones torvalds'
> 7f907d7486f2519c2ff1493bfbcdc36dcacd85b7 and creates a chain of commits
> starting with ac21e9ff08db3d6fac41d356c77fcb531c2e03e1 and ending in
> e838a0d4d5260bce452c96914a6e86b217c53c55.  torvalds merges this chain
> back into his version in a9e4820c4c170b3df0d2185f7b4130b0b2daed2c, but
> that commit has as parents e838a0d4d5260bce452c96914a6e86b217c53c55
> (gregkh's last commit), and c0698f2f6e4839ce9463ce731c892993215ea067,
> one of jejb's intermediate commits.  But now why is
> 7f907d7486f2519c2ff1493bfbcdc36dcacd85b7 not a parent of
> a9e4820c4c170b3df0d2185f7b4130b0b2daed2c?  I would expect it to be,
> since it is linus' most recent local commit when he merges in gregkh's
> tree.
>
> This pattern happens a few more times:
> - davem creates c4d541106bc5d0a2134aaf9e8735eee3c70b0db2 from torvalds'
>   561bbe3235da614562fb26bb14042af684971a2d, and torvalds merges davem's
>   tree back in at a2755a80f40e5794ddc20e00f781af9d6320fafb (v2.6.12-rc3),
>   but that commit only has one parent (even though it's a merge.)
>
> See this image:
> 	http://www.liacs.nl/~buytenh/graph_2cacb3da620a4a93f3a77e1d2c8c06bb3c74bcb0.png

Hi Lennert,

Nice work, the labelled vectors are a nice touch.  How hard would it be to
add a format where all linear commits on a single branch were listed in a
single bubble?  That would reduce the size of the graphic considerably
with no loss of info.

As for your question the top of Linus' tree at that merge was actually
commit c0698f2f6e4839ce9463ce731c892993215ea067  :

tree b05fc8a950ace937460212e996441e4c05a227f6
parent cb624029cab62e5415287d15b2ec907b8f322ff5
parent 7f907d7486f2519c2ff1493bfbcdc36dcacd85b7
author James Bottomley <jejb@titanic> 1113875709 -0500
committer James Bottomley <jejb@titanic> 1113875709 -0500

fully merge up to scsi-misc-2.6

-----

Which includes the 7f90* parent for a9e4* you were expecting.  The graph
kind of hides the fact that c069* actually originated in his tree and was
actually his most recent local commit when he merged with gregkh.

Sean

Re: question on merges

[Linus Torvalds]

On Mon, 2 May 2005, Lennert Buytenhek wrote:
> 
> If a git user has X as his most recent local commit, and merges in a
> commit Y from someone else to create commit Z, shouldn't commit Z have
> both commit X and Y as parents?  Or is is the other way round and is it
> perfectly well possible that a 'merge commit' only has one parent?

There are two classes of git merges:
 - the "totally trivial one", where one side is fully contained within the 
   other (ie one side has not done any development at all)

   In this case, the "merge" ends up being a no-op, and just ends up being 
   a trivial "update" to the bigger set of objects. There are no two 
   parents, because the merge never even creates a new commit - it just
   takes the top commit from the other side.

 - a real merge, where both repositories have had concurrent development, 
   and then you see a new merge commit that has two parents (and they'll 
   be the two HEAD commits of the repositories).

So I assume you're just seeing the trivial case, but if what you're seeing 
doesn't seem to match that pattern, then holler.

NOTE! There's a real reason why the trivial merge _has_ to be just a plain 
"fast-forward the history to the new state", namely the fact that if you 
create a new merge-node for that, then you can never ever "stabilize": 
people merging back and forth will always get new nodes, and you end up 
with this run-away situation where you can never get the same tree on both 
sides.

		Linus