Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> wrote: >> we could even store the data in a separate file to >> retain indexv2 compatibility). >> >> So it's sort-of a cache, in that it's redundant with the actual data. >> But staleness and writing issues are a lot simpler, since it only >gets >> updated when we index the pack (and the pack index in general is a >> similar concept; we are "caching" the location of the object in the >> packfile, rather than doing a linear search to look it up each time). > >I think I have something like that, (generate a machine-friendly >commit cache per pack, staying in $GIT_DIR/objects/pack/ too). It's >separate cache staying in $GIT_DIR/objects/pack, just like pack-.idx >files. It does improve rev-list time, but I'd rather wait for packv4, >or at least be sure that packv4 will not come anytime soon, before >pushing the cache route. I would love to try those patches out if you have them? -Martin Employee of Qualcomm Innovation Center,Inc. which is a member of Code Aurora Forum -- 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