I have some feature changes planned for parse-options.[ch], including
ones that allow us to delete some boilerplate (and sometimes buggy)
code in built-ins by having the API do heavier lifting.
In adding anything to the API I've found it hard to deal with it using
its own enums inconsistently, sometimes it's an "int", sometimes it's
the "enum", and having the "default" cases makes it hard to assert
that you've added things to all the right places.
2-6,7-10/10 is that rather straightforward conversion. 1,7/10 also
have fixes to existing bugs that happened due to mixing up the enum
fields in one way or the other.
Ævar Arnfjörð Bjarmason (10):
parse-options.h: move PARSE_OPT_SHELL_EVAL between enums
parse-options.[ch]: consistently use "enum parse_opt_flags"
parse-options.[ch]: consistently use "enum parse_opt_result"
parse-options.c: use exhaustive "case" arms for "enum parse_opt_type"
parse-options.h: make the "flags" in "struct option" an enum
parse-options.c: move optname() earlier in the file
commit-graph: stop using optname()
parse-options.[ch]: make opt{bug,name}() "static"
parse-options tests: test optname() output
parse-options: change OPT_{SHORT,UNSET} to an enum
builtin/blame.c | 3 +
builtin/commit-graph.c | 3 +-
builtin/shortlog.c | 3 +
parse-options.c | 116 ++++++++++++++++++++++++++-------------
parse-options.h | 26 ++++-----
t/t0040-parse-options.sh | 42 +++++++++++++-
6 files changed, 138 insertions(+), 55 deletions(-)
--
2.33.0.1340.ge9f77250f2b
