I'll be taking over this series from Glen (thank you for the work so far). Here's what I see as the current open questions: - Do we need a cleanup of return values in config.c? If so, does it need to be part of this series? - Are we OK leaving the include machinery in config.c? - If we expect non-Git-CLI projects to use config-parse as a library, should we provide alternative error-handling callbacks for (assumed) use cases, even if they won't be directly used in the Git project? (I lean to "No", but I want to make sure the option is considered.) - Does this series need to include the config-parse.c:do_event() refactor Jonathan Tan mentioned in [1]? [1]: https://lore.kernel.org/git/20230804213457.1174493-1-jonathantanmy@xxxxxxxxxx/ Changes since v1.5: - Dropped patch 1/5: config: return positive from git_config_parse_key() Glen Choo (4): config: split out config_parse_options config: report config parse errors using cb config.c: accept config_parse_options in git_config_from_stdin config-parse: split library out of config.[c|h] Makefile | 1 + builtin/config.c | 4 +- bundle-uri.c | 4 +- config-parse.c | 561 ++++++++++++++++++++++++++++++++++++++ config-parse.h | 155 +++++++++++ config.c | 655 ++++----------------------------------------- config.h | 134 +--------- fsck.c | 4 +- submodule-config.c | 9 +- 9 files changed, 795 insertions(+), 732 deletions(-) create mode 100644 config-parse.c create mode 100644 config-parse.h Range-diff against v1: 1: 9924481630 < -: ---------- config: return positive from git_config_parse_key() -: ---------- > 1: 5c676fbac3 config: split out config_parse_options -: ---------- > 2: cb92a1f2e3 config: report config parse errors using cb -: ---------- > 3: e034d0780c config.c: accept config_parse_options in git_config_from_stdin -: ---------- > 4: 74c5dcd5a2 config-parse: split library out of config.[c|h] base-commit: aa9166bcc0ba654fc21f198a30647ec087f733ed -- 2.42.0.rc1.204.g551eb34607-goog
