On Tue, Aug 28, 2007 at 12:28:39PM +0100, Johannes Schindelin wrote:

quoted text
> Most comparisons (I guess) would be relatively cheap, since the traversals 
> alone would suffice, and most of the others would be relatively short.
> 
> But I really wonder now if it is not just easier to increase 
> MERGE_TRAVERSAL_WEIGHT to (1<<24) and be done with it once and (probably) 
> for all.

Yes, I am beginning to think this is getting very complex for a problem
that really hasn't proven itself to be worth considering. Sure, I
suppose name-rev is a little bit of a memory hog, but running Uwe's
tests only consumed about 17M even on my static implementation. That
really isn't enough to worry about.

I still prefer my implementation to the MERGE_TRAVERSAL_WEIGHT, but that
is perhaps a matter of preference. With mine, you could plug in
comparators to tweak the names (e.g., number of intervening
commits instead of minimizing merge traversals) but I'm not 100% sure
that's useful.

This seems related to gitk's "follows, precedes". I wonder what
algorithm that uses. I think I'll have to find out after some sleep,
though.

-Peff
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html