Linus Torvalds [off-list ref] writes:
On Sun, 23 Oct 2005, Junio C Hamano wrote:
quoted
Even if we did that, we are still doing 3-way merge; git-merge
framework may not mesh very well when we want to use something
like codeville merge which is not based on 3-way.
Oh, the git merge is about a million times better than any silly weave
merge with extra BonusPoints and MagicCapitalizedNames.
Why? Because if you want to be slow and careful, you can always just
create the weave after-the-fact and do a weave merge.
Yes, I know that as the one who did the convention between
git-merge and merge strategy backends. The convention feeds two
(or more) heads and the common ancestors git-merge already
figured out to the strategy backends.
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.
On Sun, 23 Oct 2005, Junio C Hamano wrote:
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