[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: Why is "git tag --contains" so slow?
From:       Theodore Tso <tytso () MIT ! EDU>
Date:       2010-07-08 10:29:04
Message-ID: 11D5771D-EB47-42E9-BCC3-69C8FE1999EC () MIT ! EDU
[Download RAW message or body]


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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]