On Thu, Jul 08, 2010 at 06:29:04AM -0400, Theodore Tso wrote: > 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? It sounds reasonable to me. It just needs somebody to design and implement it. :) I don't know anything about how gitk.cache works. Caching tag refs is not that hard, because the refs tend not to change. Doing arbitrary "X contains Y" caching is much harder, and I think you would have to build it on Nick's rev-cache work. Maybe he (cc'd) has some ideas. -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