Re: Automatic merge failed, fix up by hand

From: Junio C Hamano <junkio@cox.net>
Date: Aug 24, 2005, 03:52 UTC
Message-ID: <7vhddgj8j0.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.58.0508231823420.3317@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

Show 12 quoted lines

> Ok, I think your approach is the correct one. Just list all the commits, 
> and let the merge logic figure out which one is the best one.
>
> Just returning several entries is the correct thing to do, because then
> you can make the distance function be based on the tree diffs, like you
> do. That's _much_ better than trying to make the distance be based on some
> topology.
>
> So I append this patch just as a historical curiosity. Junio's patch is 
> clearly superior.
>
> 		Linus

Of course it is clearly superior, because it is not _my_ patch but *yours*.

I just did what you earlier told the world how things should work, based on this message:

    Date:	Mon, 11 Apr 2005 16:48:25 -0700 (PDT)
    From:	Linus Torvalds <torvalds@osdl.org>
    Subject: Re: git: patch for parent-id and idea for merge
    Message-ID: <Pine.LNX.4.58.0504111631360.1267@ppc970.osdl.org>

    Btw, I've changed the semantics of "rev-tree" once again.
    ...
    In other words, it will give you a way to figure out which changeset to
    use as the common one. It's always going to be a parent of one of these
    edge-commits that has all of its reachability bits set. Which one.. Now
    that's the question. Maybe just the most recent one, or maybe actually use
    "diff-tree" to see which one generates the fewest conflicts.