Re: LCA2006 Git/Cogito tutorial

From: Linus Torvalds <torvalds@osdl.org>
Date: Oct 24, 2005, 03:32 UTC
Message-ID: <Pine.LNX.4.64.0510232020030.10477@g5.osdl.org>
In-Reply-To: <7vy84jsn1o.fsf@assigned-by-dhcp.cox.net>

On Sun, 23 Oct 2005, Junio C Hamano wrote:

Show 8 quoted lines

> 
> The current callers only feed commits for "$heads" parameters,
> so the merge strategy backends are free to figure out the common
> ancestor or even generate weave on the fly, but an unwritten
> rule was that strategy backends are expected to do something
> sensible even when the "common ancestors" and "heads" fed to
> them are tree objects, which was my comment about 3-way was
> about.

Ahh. Yes, if you use raw trees, you're screwed - you can only ever do a 3-way merge, since you can't try to figure out any history.

I agree that the "tree only" case is interesting too - it's how you can merge trees that may be related content-wise but don't share a history (eg the same project maintained in separate source trees), and it's obviously how you can merge totally unrelated projects (eg the gitk merge). At the same time, I think that's a different kind of merge, in general. And we definitely shouldn't limit ourselves to things where such merges work.

Yes, tree-merges are wonderful, and they work really quite well, but I definitely want to keep the window open for merges that end up taking the full history into account.

I just don't think they are nearly as important as some people seem to think. They should be a very special and unusual case, rather than something you expect to happen.

		Linus