Re: another packed-refs race
- From
Johan Herland <johan@herland.net>
- Date
- May 3, 2013, 21:02 UTC
- Message-ID
- <CALKQrgdG2QOs4Z0vAg7cZt8F5LKd4X8pMMAS0C2HcztbzaBBeQ@mail.gmail.com>
- In-Reply-To
- <20130503182649.GA25379@sigill.intra.peff.net>
On Fri, May 3, 2013 at 8:26 PM, Jeff King <peff@peff.net> wrote:
Show 25 quoted lines
> 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