Am 13.11.22 um 06:01 schrieb Taylor Blau: > On Sat, Nov 12, 2022 at 11:58:44AM -0500, Jeff King wrote: >> On Sat, Nov 12, 2022 at 11:44:00AM +0100, René Scharfe wrote: >> >>> Since 5cb28270a1 (pack-objects: lazily set up "struct rev_info", don't >>> leak, 2022-03-28) --filter options given to git pack-objects overrule >>> earlier ones, letting only the leftmost win and leaking the memory >>> allocated for earlier ones. Fix that by only initializing the rev_info >>> struct once. >> >> Yikes. I wondered how we managed to miss this in the tests. Surely we >> have some examples that use multiple filters? >> >> I think the answer is that we do in t5616, but in practice they didn't >> hit this bug because of the way filter-specs are treated server-sid3. >> Even if we say "clone --filter=foo --filter=bar" on the client, the >> server upload-pack coalesces that into a single "combine:foo+bar" >> string, and that's what its pack-objects sees. > > ...Or in other words, clients aren't broken here because we always send > "combine" filters when multiple `--filter` arguments are passed to `git > clone`, `git fetch`, etc. > > Is that always the case? I *think* so, but it would be nice to know if > there was a way that clients would not send the `combine` filter with >1 > filter. Searching for pack-objects invocations like this should at least find all internal cases, right? $ git grep -e '"pack-objects"' -e --filter --all-match --name-only builtin/pack-objects.c bundle.c upload-pack.c git pack-objects handles --filter and doesn't pass it on. bundle.c and upload-pack.c only add at most a single --filter option to a strvec. bundle.c uses list_objects_filter_spec() to get the filter specification, upload-pack.c uses expand_list_objects_filter_spec(). René
