Re: question on merges

From: Linus Torvalds <torvalds@osdl.org>
Date: May 2, 2005, 15:56 UTC
Message-ID: <Pine.LNX.4.58.0505020850500.3824@ppc970.osdl.org>
In-Reply-To: <20050502151200.GA4592@xi.wantstofly.org>

On Mon, 2 May 2005, Lennert Buytenhek wrote:

Show 5 quoted lines

> 
> 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