Re: [PATCH 2/3] pack-object: simplify --filter handling
- From
René Scharfe <l.s.r@web.de>
- Date
- Nov 13, 2022, 17:31 UTC
- Message-ID
- <0222bc92-bbea-6947-3523-cb10edece9bb@web.de>
- In-Reply-To
- <Y2/Rwvb2uiE40rW0@coredump.intra.peff.net>
Am 12.11.22 um 18:02 schrieb Jeff King:
Show 21 quoted lines
> On Sat, Nov 12, 2022 at 11:44:50AM +0100, René Scharfe wrote: > >> pack-objects uses OPT_PARSE_LIST_OBJECTS_FILTER_INIT() to initialize the >> a rev_info struct lazily before populating its filter member using the >> --filter option values. It tracks whether the initialization is needed >> using the .have_revs member of the callback data. >> >> There is a better way: Use a stand-alone list_objects_filter_options >> struct and build a rev_info struct with its .filter member after option >> parsing. This allows using the simpler OPT_PARSE_LIST_OBJECTS_FILTER() >> and getting rid of the extra callback mechanism. > > That seems like a reasonable fix (and I think we do it elsewhere). But I > wonder if it wouldn't be simpler to just unconditionally initialize the > rev_info in cmd_pack_objects(), and then unconditionally release it. > True, we _might_ not use it if we are receiving objects directly over > stdin, but I don't think initializing it is particularly costly. > > And then we don't have to worry about whether it's valid (it always is), > or about copying between two representations of the filter (there's only > one).
Indeed that's even simpler and what we had before 5cb28270a1 (pack-objects: lazily set up "struct rev_info", don't leak, 2022-03-28).
René