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. Your test here triggers it by invoking pack-objects directly, which makes sense. That's a little different from how pack-objects is invoked by the rest of Git in practice, but it's definitely something that _should_ work. It's conceivable that somebody outside of Git could be driving pack-objects directly, but also it's just a trap waiting to spring for future developers. -Peff
