Jeff King <peff@xxxxxxxx> writes: > I'd be more worried about correctness (command "foo" must not parse > option "bar" because it is plumbing and must use the default). But > looking over the options, I really don't see anything like that. The one > I'd expect (or worry most about) is "we do/do not bother to enable > signatures at all based on config" but I don't think that is the case. > We default use_format to &gpg_format[0], so there is always a signature > format defined, even if the config is skipped. I arrived at the same conclusion after seeing what these configuration affected. If some plumbing codepaths should avoid certain gpg-interface features, I didn't see a good reason for them to be calling into gpg-interface.c functions (e.g. that would have meant that "rev-list '--format=%G'" should have errored out with a "%G is only available in log but not in rev-list which is a plumbing" error message) and at that point reading configuration is much lessor problem. > If the gpg code used git_config_get_string(), etc, then they could just > access each key on demand (efficiently, from an internal hash table), > which reduces the risk of "oops, we forgot to initialize the config > here". It does probably mean restructuring the code a little, though > (since you'd often have an accessor function to get "foo.bar" rather > than assuming "foo.bar" was parsed into an enum already, etc). That may > not be worth the effort (and risk of regression) to convert. Yup. Care must be taken not to break "-u <keyid>" that is set via calling set_signing_key() directly, which assumes that the default key is already set from the config earlier, but the resulting code may make it clearer that our rule is "command line first, and then peek into configuration as a fallback value", if we did such a conversion. Thanks.
