Re: question on merges

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