Re: [PATCH 10/14] (RFC-only) config: finish config_fn_t refactor
- From
Glen Choo <chooglen@google.com>
- Date
- May 8, 2023, 21:00 UTC
- Message-ID
- <kl6lr0rq1qt8.fsf@chooglen-macbookpro.roam.corp.google.com>
- In-Reply-To
- <230501.868re8jna4.gmgdl@evledraar.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
Show 21 quoted lines
> On Fri, Apr 21 2023, Glen Choo via GitGitGadget wrote: > >> From: Glen Choo <chooglen@google.com> > > I like the general goal of this series, i.e. to get rid of the "reader" > callback, and pass stuff more explicitly. > > But as I pointed out in > https://lore.kernel.org/git/RFC-cover-0.5-00000000000-20230317T042408Z-avarab@gmail.com/ > I think this part (and the preceding two commits) are really taking is > down the wrong path. > > To demonstrate why, here's a patch-on-top of this topic as a whole where > I renamed the "kvi" struct members. I've excluded config.c itself (as > its internals aren't interesting for the purposes of this discussion): > > [Patch showing used kvi members...] > > So, as this shows us your 08/14 has gone through the effort of passing > this "kvi" info to every single callback, but it's only this handful > that actually needs this information.
The attached patch misses the majority of "kvi" users, which use it in die_bad_number(). This change happens in Patch 13/14, where the whole "kvi" is passed into config.c machinery. It's still a much smaller number of config callbacks than the ones changed in these few patches, but it's more than a handful, I'd think.
> So, even if we *can* get this to work I don't think it's worth it, > especially as this would preclude giving these config callbacks some > "lighter" API that doesn't take the trouble of recording and ferrying > this information to them.
I assume the "lighter API" refers to the current API?
If I'm reading this correctly, your concern isn't primarily about reducing churn, it's YAGNI - since most callers don't need this info, they should be able to reap the benefits of an API that doesn't provide that info. Thus, you're proposing to having both the current API and a new kvi-based one?
If so, I don't think that's a good route to take:
- Having both *_kvi() and "old" variants will add bloat to an already bloated config API. Even without further changes, we'd need to add *_kvi() to at least config_with_options() and repo_config(), as well as all of the functions that config_with_options() uses under the hood (some of which are public).
To some extent, this can be managed by shrinking the config API (e.g. like your suggestion to get rid of git_config_from_file() [1]), but IMO that needs more discussion.
- What benefit is the old API giving us vs the new one? It won't be any faster since the machinery will need to support the new API, and even if it were, the benefit would be tiny. In some cases it might be nice to use the config callback in a non-config setting, but this patch shows that those are rare and can be easily worked around.
- I strongly suspect that we'd already like "kvi" in more places, and if we made it readily available, we would add these additional callers. E.g. we already use it to give additional diagnostics when failing to parse a number, and there's no reason why we shouldn't do this when doing other kinds of parsing (e.g. date in git_config_expiry_date() or color in color_parse_mem()).
If your concern really is primarily about churn and we actually want to move everything to the new API eventually, wouldn't it be better to bite the bullet and take a one time, well-scoped churn cost instead of a longer migration?
[1] https://lore.kernel.org/git/230307.86wn3szrzu.gmgdl@evledraar.gmail.com/
Show 5 quoted lines
> I think this should also neatly answer some of your outstanding > questions. Especially as the above shows that the only non-test caller > that needs "linenr" is the builtin/config.c caller that my proposed RFC > (linked above) tackled directly. Most of these callbacks just need the > more basic "scope".
I didn't see where builtin/config.c was handled in the above link. Perhaps you meant a different RFC, https://github.com/avar/git/commit/0233297a359bbda43a902dd0213aacdca82faa34?
Show 15 quoted lines
> So, in particular: > >> Here's an exhaustive list of all of the changes: >> >> * Cases that need a judgement call >> >> - trace2/tr2_cfg.c:tr2_cfg_set_fl() >> >> This function needs to account for tr2_cfg_cb() now using "kvi". >> Since this is only called (indirectly) by git_config_set(), config >> source information has never been available here, so just pass NULL. >> It will be tr2_cfg_cb()'s responsibility to not use "kvi". > > Just adding a "CONFIG_SCOPE_IN_PROCESS", "CONFIG_SCOPE_SET" or whatever > you'd want to call it seems to make much more sense here, no?
CONFIG_SCOPE_SET makes sense.
Show 10 quoted lines
>> - builtin/checkout.c:checkout_main() >> >> This calls git_xmerge_config() as a shorthand for parsing a CLI arg. >> "kvi" doesn't apply, so just pass NULL. This might be worth >> refactoring away, since git_xmerge_config() can call >> git_default_config(). > > Another example of a caller which never actually cares about this data, > so if it doesn't need to have it passed to it, it doesn't need to fake > it up either.
Here's a case of YAGNI I mentioned above and I agree it would be nice to not have to fake a "kvi". However, git_xmerge_config() can call git_defualt_config() so this seems more like it's abusing the config callback to parse a CLI arg. A better resolution would be to have a function dedicated to parsing "merge.conflictstyle".
Show 53 quoted lines
>> * Hard for cocci to catch >> >> - urlmatch.c >> >> Manually refactor the custom config callbacks in "struct >> urlmatch_config". >> >> - diff.h, fsck.h, grep.h, ident.h, xdiff-interface.h >> >> "struct key_value_info" hasn't been defined yet, so forward declare >> it. Alternatively, maybe these files should "#include config.h". > > All of these problems go away if you don't insist on changing every > single caller, you'll just have a step where you remove the current > global in favor of some "config callback with kvi" info, and "make" will > spot those callers that aren't converted yet. > > Those changes will be trivial enough (just the callers I noted above) to > not require the tricky cocci patch in 08/14. > >> * Likely deficiencies in .cocci patch >> >> - submodule-config.c:gitmodules_cb() >> >> Manually refactor a parse_config() call that gets missed because it >> uses a different "*data" arg. >> >> - grep.h, various >> >> Manually refactor grep_config() calls. Not sure why these don't get >> picked up. >> >> - config.c:git_config_include(), http.c:http_options() >> >> Manually add "kvi" where it was missed. Not sure why they get missed. >> >> - builtin/clone.c:write_one_config() >> >> Manually refactor a git_clone_config() call. Probably got missed >> because I didn't include git_config_parse_parameter(). >> >> - ident.h >> >> Remove the UNUSED attribute. Not sure why this is the only instance >> of this. >> >> - git-compat-util.h, compat/mingw.[h|c] >> >> Manually refactor noop_core_config(), platform_core_config() and >> mingw_core_config(). I can probably add these as "manual fixups" in >> cocci. > > ditto.
Yeah, there was definitely more cocci trickery than I'd like. Btw, if you comments on the .cocci file itself, feel free to share. I obviously just hacked together something based on a very rudimentary understanding of cocci and I'd love suggestions on how to improve.