On Mon, Jul 11, 2011 at 09:46, Jeff King <peff@xxxxxxxx> wrote: > On Mon, Jul 11, 2011 at 12:17:54PM -0400, Jeff King wrote: > >> +Storage >> +------- >> [...] >> +The disk storage consists of a single file per cache, located in the >> +`$GIT_DIR/cache` directory. Each file contains a list of rows ordered by >> +sha1. Each row contains a binary sha1, followed by the fixed-size data >> +mapped to that sha1. > > There's nothing else in the file, not even a header. I should probably > add at least a version byte, in case we ever do want to change what goes > into a cache (in which case we could just blow away what's there and > regenerate). Please do. We don't always need to invent a new version... but for a cache file its probably more common than the PACK network stream, or the pack-*.idx file. And its painful to shoehorn in a version change after the fact. > We could also have a "validity" field that must match for the cache to > be valid. Junio mentioned earlier that you would want to regenerate a > generations cache whenever grafts or replace objects changed. It > wouldn't be hard to do something like: > > validity = sha1(grafts + replace); > if (validity != cache_validity) > empty_disk_cache(); > > And then it would just automatically work, without the user having to > remember to clear the cache. Calculating the validity would be cheap in > the common case (you have no grafts or replace objects), and not much > more expensive when you do have them (we have to read that data anyway > to respect the replacements). This is a pretty good idea too. Saves the hapless user from surprises when they forget the cache exists, but they changed grafts or replace data. -- Shawn. -- 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