Patrick Steinhardt <ps@xxxxxx> writes: > So if the code were refactored to instead accept an arbitrary `void *` > pointer, callers could provide a custom structure and pass that along to > its subcommands. In many cases we may end up just passing the repo > directly, but I'm sure there are others where this direction would buy > us additional flexibility and allow us to get rid of even more global > state. I am of two minds. Certainly for OPT_SUBCOMMAND macro to be able to work with arbitrary types that are specific to each git subcommand, we'd need "void *" plus casting on the receiving end. But it loses type safety. I personally think (but not so strongly) that we should add a repo to parse_opt_subcommand_fn(), if this exercise is about giving consistent access to the repository object universally across subsubcommands. If we want flexibility on top, we can either add another "void *" for it after we are done with adding the repository, or we may even be able to make the parse_opt_subcommand_fn() a varargs.
