Re: another packed-refs race

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]