From: Johan Herland Date: Fri, 03 May 2013 21:02:48 GMT Subject: Re: another packed-refs race Message-ID: In-Reply-To: <20130503182649.GA25379@sigill.intra.peff.net> On Fri, May 3, 2013 at 8:26 PM, Jeff King 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, www.herland.net