Re: [PATCH 1/3] pack-objects: fix handling of multiple --filter options

From: Jeff King <peff@peff.net>
Date: Nov 12, 2022, 16:58 UTC
Message-ID: <Y2/QxOnM/7UI4R8c@coredump.intra.peff.net>
In-Reply-To: <53bffbf4-8308-0dd7-bca5-7c85b8334e05@web.de>

On Sat, Nov 12, 2022 at 11:44:00AM +0100, René Scharfe wrote:

Show 5 quoted lines

> 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