Am 12.11.22 um 18:02 schrieb Jeff King: > 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é
