On Wed, 20 Apr 2005, Petr Baudis wrote:
> Dear diary, on Wed, Apr 20, 2005 at 12:17:12AM CEST, I got a letter
> where Daniel Barkalow <[EMAIL PROTECTED]> told me that...
>
> > I can think of. Are you sure there isn't another path to 5b53d3?
>
> I'm not. Actually there well might be.
>
> I think merge-base should never take a path which is effectively
> "upside-down" when a straight "upside" one is available.
>
> Hmm. So what I depended on for merge-base was that when doing it on A
> and B and A is predecessor of B, then it will always just return A. I
> will perhaps need to abuse rev-tree somehow for this then, it looks.
It is currently optimizing for the shortest longer path, but I guess it
should optimize for the shortest shorter path (i.e., the 0-length path
from A to itself always wins).
On the other hand, the date-based comparison (which you'd get with the
version I sent yesterday with [2/4] and [4/4]) would give you the most
recent common ancestor, which would necessarily avoid this situation.
Do you want to go with the date-based approach, or should I work out a
shortest shorter path algorithm?
-Daniel
*This .sig left intentionally blank*
-
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
