Glen Choo <chooglen@xxxxxxxxxx> writes: > By configset interface, I believe you mean the O(1) lookup functions > like git_config_get_int() (which rely on the value being cached, but > don't necessarily accept "struct config_set" as an arg)? I think that > makes sense both from a performance and maintenance perspective. Ah, yes. (More precisely, not the one where you call something like repo_config(), passing a callback function that.) > Given how painful it is to change the config_fn_t signature, I think it > is important to get as right as possible the first time. After I sent > this out, I thought of yet another possible config_fn_t signature > (since most callbacks only need diagnostic information, we could pass > "struct key_value_info" instead of the more privileged "struct > config_reader"), but given how many functions we'd have to change, it > seemed extremely difficult to even begin experimenting with this > different signature. Yeah, the first change is the hardest. I think passing it a single struct (so, instead of key, value, data, reader, and then any future fields we would need) to which we can add fields later would mean that we wouldn't need any changes beyond the first, though.
