Re: another packed-refs race

On Fri, May 3, 2013 at 8:26 PM, Jeff King [off-list ref] wrote:

On Fri, May 03, 2013 at 01:28:53PM -0400, Jeff King wrote:

quoted

quoted

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, [off-list ref]
www.herland.net