Jeff King <peff@xxxxxxxx> writes: > Yeah, my intent had been to circle back around to this, but I just > hadn't gotten to it. I'm still pondering a config option or similar, > though I remain unconvinced that the cases in which you've showed it > being slow are actually realistic or worth worrying about (and certainly > having an obscure config option is not enough to help most people). If > we could have it kick in heuristically, that would be better. Me neither and I agree. > However, note that the cache-load for finding abbreviations _must_ have > the complete list. And has been loading it for some time. So if you run > "git-fetch", for example, you've already been running this code for > months (and using the cache in more places is now a free speedup). > > At the very least, we'd want this patch on top, too. I also think René's > suggestion use access() is worth pursuing (though to some degree is > orthogonal to the cache). OK, will queue, but I wonder where 66f0 comes from before silently doing s/66f04152be/3a2e08245c/ myself. > -- >8 -- > Subject: [PATCH] odb_load_loose_cache: fix strbuf leak > > Commit 66f04152be (object-store: provide helpers for > loose_objects_cache, 2018-11-12) moved the cache-loading code from > find_short_object_filename(), but forgot the line that releases the path > strbuf. > > Reported-by: René Scharfe <l.s.r@xxxxxx> > Signed-off-by: Jeff King <peff@xxxxxxxx> > --- > sha1-file.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/sha1-file.c b/sha1-file.c > index 5894e48ea4..5a272f70de 100644 > --- a/sha1-file.c > +++ b/sha1-file.c > @@ -2169,6 +2169,7 @@ void odb_load_loose_cache(struct object_directory *odb, int subdir_nr) > NULL, NULL, > &odb->loose_objects_cache); > odb->loose_objects_subdir_seen[subdir_nr] = 1; > + strbuf_release(&buf); > } > > static int check_stream_sha1(git_zstream *stream,
