On Fri, May 3, 2013 at 8:26 PM, Jeff King <p...@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, <jo...@herland.net> www.herland.net -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
