Skip to content

config-parse: create config parsing library

Glen Choo via GitGitGadget git 1 version In review

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest2 patches 6 repliesIn review

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/2config: return positive from git_config_parse_key()builtin/config.c config.c config.h +2 more+28 -134 replies
2/2config-parse: split library out of config.[c|h]Makefile config-parse.c config-parse.h +2 more+795 -7772 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [PATCH 0/2] config-parse: create config parsing library

Config parsing no longer uses global state as of gc/config-context, so the natural next step for libification is to turn that into its own library. This series starts that process by moving config parsing into config-parse.[c|h] so that other programs can include this functionality without pulling in all of config.[c|h].

To use config-parse.[c|h], an external caller has to obey our convention of using "#include git-compat-util.h" at the start of the .c file. This is doable by including the in-tree git-compat-util.h and linking against the libgit.a Make target (which is admittedly cumbersome), and we've verified this by compiling and linking to the library using the Google-internal version of Bazel.

This series is not meant to distract from Calvin's git-std-lib series [1]. In fact, the two are complementary: git-std-lib will make it possible for external callers to compile a smaller subset of files in order to use a library. Doing this for config-parse will make config-parse easier to use, while testing that git-std-lib does what we want it to.

I considered calling the library config-ll (like we do in other parts of the codebase) instead of config-parse, with the intention of adding more "low level" config code to it in the future. A benefit to that is that by having fewer modules, dependency management is easier to reason about. However, I struggled to think of what other config code could be considered "low level" but doesn't make sense as its own module. (E.g. struct config_set is a low level implementation detail, but I think it's well-scoped enough to be its own config-set module.) I'd appreciate suggestions on how the config libraries could be organized.

[1]
https://lore.kernel.org/git/[email protected]/

Glen Choo (2):
config: return positive from git_config_parse_key()
config-parse: split library out of config.[c|h]

 Makefile           |   1 +
 builtin/config.c   |   3 +-
 config-parse.c     | 611 +++++++++++++++++++++++++++++++++++++++++++
 config-parse.h     | 182 +++++++++++++
 config.c           | 636 +--------------------------------------------
 config.h           | 146 +----------
 submodule-config.c |   4 +-
 t/t1300-config.sh  |  16 ++
 8 files changed, 816 insertions(+), 783 deletions(-)
 create mode 100644 config-parse.c
 create mode 100644 config-parse.h

base-commit: aa9166bcc0ba654fc21f198a30647ec087f733ed
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1551%2Fchooglen%2Fconfig%2Fparse-lib-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1551/chooglen/config/parse-lib-v1
Pull-Request: https://github.com/git/git/pull/1551

Signature · 1 line
gitgitgadget