git/parse-options.h, branch v2.35.2

Merge branch 'js/branch-track-inherit'

2022-01-10T19:52:54Z

"git -c branch.autosetupmerge=inherit branch new old" makes "new" to have the same upstream as the "old" branch, instead of marking "old" itself as its upstream. * js/branch-track-inherit: config: require lowercase for branch.*.autosetupmerge branch: add flags and config to inherit tracking branch: accept multiple upstream branches for tracking

branch: add flags and config to inherit tracking

2021-12-21T06:40:21Z

It can be helpful when creating a new branch to use the existing tracking configuration from the branch point. However, there is currently not a method to automatically do so. Teach git-{branch,checkout,switch} an "inherit" argument to the "--track" option. When this is set, creating a new branch will cause the tracking configuration to default to the configuration of the branch point, if set. For example, if branch "main" tracks "origin/main", and we run `git checkout --track=inherit -b feature main`, then branch "feature" will track "origin/main". Thus, `git status` will show us how far ahead/behind we are from origin, and `git pull` will pull from origin. This is particularly useful when creating branches across many submodules, such as with `git submodule foreach ...` (or if running with a patch such as [1], which we use at $job), as it avoids having to manually set tracking info for each submodule. Since we've added an argument to "--track", also add "--track=direct" as another way to explicitly get the original "--track" behavior ("--track" without an argument still works as well). Finally, teach branch.autoSetupMerge a new "inherit" option. When this is set, "--track=inherit" becomes the default behavior. [1]: https://lore.kernel.org/git/20180927221603.148025-1-sbeller@google.com/ Signed-off-by: Josh Steadmon Signed-off-by: Junio C Hamano

Merge branch 'ab/parse-options-cleanup'

2021-11-09T21:19:06Z

Last minute fix to the update already in 'master'. * ab/parse-options-cleanup: parse-options.[ch]: revert use of "enum" for parse_options()

parse-options.[ch]: revert use of "enum" for parse_options()

2021-11-09T17:45:37Z

Revert the parse_options() prototype change in my recent 352e761388b (parse-options.[ch]: consistently use "enum parse_opt_result", 2021-10-08) was incorrect. The parse_options() function returns the number of argc elements that haven't been processed, not "enum parse_opt_result". Reported-by: SZEDER Gábor Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Merge branch 'ab/parse-options-cleanup'

2021-10-25T23:06:59Z

Random changes to parse-options implementation. * ab/parse-options-cleanup: parse-options: change OPT_{SHORT,UNSET} to an enum parse-options tests: test optname() output parse-options.[ch]: make opt{bug,name}() "static" commit-graph: stop using optname() parse-options.c: move optname() earlier in the file parse-options.h: make the "flags" in "struct option" an enum parse-options.c: use exhaustive "case" arms for "enum parse_opt_result" parse-options.[ch]: consistently use "enum parse_opt_result" parse-options.[ch]: consistently use "enum parse_opt_flags" parse-options.h: move PARSE_OPT_SHELL_EVAL between enums

Merge branch 'ab/help-config-vars'

2021-10-13T22:15:58Z

Teach "git help -c" into helping the command line completion of configuration variables. * ab/help-config-vars: help: move column config discovery to help.c library help / completion: make "git help" do the hard work help tests: test --config-for-completion option & output help: simplify by moving to OPT_CMDMODE() help: correct logic error in combining --all and --guides help: correct logic error in combining --all and --config help tests: add test for --config output help: correct usage & behavior of "git help --guides" help: correct the usage string in -h and documentation

parse-options.[ch]: make opt{bug,name}() "static"

2021-10-08T21:13:11Z

Change these two functions to "static", the last user of "optname()" outside of parse-options.c itself went away in the preceding commit, for the reasons noted in 9440b831ad5 (parse-options: replace opterror() with optname(), 2018-11-10) we shouldn't be adding any more users of it. The "optbug()" function was never used outside of parse-options.c, but was made non-static in 1f275b7c4ca (parse-options: export opterr, optbug, 2011-08-11). I think the only external user of optname() was the commit-graph.c caller added in 09e0327f57 (builtin/commit-graph.c: introduce '--max-new-filters=', 2020-09-18). Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

parse-options.h: make the "flags" in "struct option" an enum

2021-10-08T21:13:11Z

Change the "flags" members of "struct option" to refer to their corresponding "enum" defined earlier in the file. The benefit of changing this to an enum isn't as great as with some "enum parse_opt_type" as we'll always check this as a bitfield, so we can't rely on the compiler checking "case" arms for us. But let's do it for consistency with the rest of the file. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

parse-options.[ch]: consistently use "enum parse_opt_result"

2021-10-08T21:13:11Z

Use the "enum parse_opt_result" instead of an "int flags" as the return value of the applicable functions in parse-options.c. This will help catch future bugs, such as the missing "case" arms in the two existing users of the API in "blame.c" and "shortlog.c". A third caller in 309be813c9b (update-index: migrate to parse-options API, 2010-12-01) was already checking for these. As can be seen when trying to sort through the deluge of warnings produced when compiling this with CC=g++ (mostly unrelated to this change) we're not consistently using "enum parse_opt_result" even now, i.e. we'll return error() and "return 0;". See f41179f16ba (parse-options: avoid magic return codes, 2019-01-27) for a commit which started changing some of that. I'm not doing any more of that exhaustive migration here, and it's probably not worthwhile past the point of being able to check "enum parse_opt_result" in switch(). Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

parse-options.[ch]: consistently use "enum parse_opt_flags"

2021-10-08T21:13:11Z

Use the "enum parse_opt_flags" instead of an "int flags" as arguments to the various functions in parse-options.c. Even though this is an enum bitfield there's there's a benefit to doing this when it comes to the wider C ecosystem. E.g. the GNU debugger (gdb) will helpfully detect and print out meaningful enum labels in this case. Here's the output before and after when breaking in "parse_options()" after invoking "git stash show": Before: (gdb) p flags $1 = 9 After: (gdb) p flags $1 = (PARSE_OPT_KEEP_DASHDASH | PARSE_OPT_KEEP_UNKNOWN) Of course as noted in[1] there's a limit to this smartness, i.e. manually setting it with unrelated enum labels won't be caught. There are some third-party extensions to do more exhaustive checking[2], perhaps we'll be able to make use of them sooner than later. We've also got prior art using this pattern in the codebase. See e.g. "enum bloom_filter_computed" added in 312cff52074 (bloom: split 'get_bloom_filter()' in two, 2020-09-16) and the "permitted" enum added in ce910287e72 (add -p: fix checking of user input, 2020-08-17). 1. https://lore.kernel.org/git/87mtnvvj3c.fsf@evledraar.gmail.com/ 2. https://github.com/sinelaw/elfs-clang-plugins/blob/master/enums_conversion/README.md Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano