Linus Torvalds <[EMAIL PROTECTED]> writes:
> 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
> So I append this patch just as a historical curiosity. Junio's patch is
> clearly superior.
Of course it is clearly superior, because it is not _my_ patch
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 <[EMAIL PROTECTED]>
Subject: Re: git: patch for parent-id and idea for merge
Message-ID: <[EMAIL PROTECTED]>
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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html