On Jul 7, 2010, at 1:45 PM, Jeff King wrote: > And of course it's just complex, and I tend to shy away from > complexity when I can. The question to me comes back to (1) above. > Is massive clock skew a breakage that should produce a few > incorrect results, or is it something we should always handle? Going back to the question that kicked off this thread, I wonder if there is some way that cacheing could be used to speed up the all cases, or at lest the edge cases, without imposing as much latency as tracking the max skew? i.e., some thing like gitk's gitk.cache file. For bonus points, it could be a cache file that is used by both gitk and git tag --contains, git branch --contains, and git name-rev. Does that sound like reasonable idea? --Ted -- 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