On Tue, Aug 28, 2007 at 12:28:39PM +0100, Johannes Schindelin wrote: > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
