Re: Why is "git tag --contains" so slow?

From: Jakub Narebski <jnareb@gmail.com>
Date: Jul 8, 2010, 11:12 UTC
Message-ID: <m37hl6mdnb.fsf@localhost.localdomain>
In-Reply-To: <11D5771D-EB47-42E9-BCC3-69C8FE1999EC@MIT.EDU>

Theodore Tso <tytso@MIT.EDU> writes:

Show 15 quoted lines

> 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?

By the way, what had happened to the rev-cache project from GSoC 2009?

-- 
Jakub Narebski
Poland
ShadeHawk on #git