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). -Peff
