Re: another packed-refs race

[Johan Herland <johan@herland.net>]

On Fri, May 3, 2013 at 8:26 PM, Jeff King <peff@peff.net> wrote:
> On Fri, May 03, 2013 at 01:28:53PM -0400, Jeff King wrote:
>> > The following solution might work in both the resolve-a-single-ref and
>> > enumerating-refs case:
>> >
>> > 0. Look for ref already cached in memory. If found, OK.
>> >
>> > 1. Look for loose ref. If found, OK.
>> >
>> > 2. If not found, load all loose refs and packed-refs from disk (in
>> > that order), and store in memory for remainder of this process. Never
>> > reload packed-refs from disk (unless you also reload all loose refs
>> > first).
>>
>> I think that would be correct (modulo that step 1 cannot happen for
>> enumeration). But we would like to avoid loading all loose refs if we
>> can. Especially on a cold cache, it can be quite slow, and you may not
>> even care about those refs for the current operation (I do not recall
>> the exact original motivation for the lazy loading, but it was something
>> along those lines).
>
> Actually, forgetting about enumeration for a minute, that would make
> single-ref lookup quite painful. Running "git rev-parse foo" shouldn't
> have to even look at most loose refs in the first place. It should be a
> couple of open() calls looking for the right spot, and then fall back to
> loading packed-refs.

True. I was overemphasizing the case where we start looking up one
ref, and later look up more refs from the same process (in which case
the load-everything step would be amortized across the other lookups),
but this is probably not the ref access pattern for most Git commands,
and definitely not for "git rev-parse foo". I think your approach is
better.


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net