Re: [PATCH v3] bisect--helper: convert a function in shell to C
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Mar 23, 2016, 11:57 UTC
- Message-ID
- <alpine.DEB.2.20.1603231238180.4690@virtualbox>
- In-Reply-To
- <01020153a254974b-68f7d16a-66d7-4dc1-805d-2185ff1b3ebf-000000@eu-west-1.amazonses.com>
Hi Pranit,
On Wed, 23 Mar 2016, Pranit Bauva wrote:
> Convert the code literally without changing its design even though it > seems that it is obscure as to the use of comparing revision to different > bisect arguments which seems like a problem in shell because of the way > function arguments are handled.
I still believe that it would make for an improvement to replace "revision" by "orig_term".
Show 5 quoted lines
> The argument handling is kind of hard coded right now because it is not > really be meant to be used like this and this is just for testing > purposes whether this new method is as functional as its counter part. > The shell counter part of the method has been retained for historical > purposes.
Well, maybe the argument handling is really meant to be used like this in the end? Just skip that paragraph.
> Also using OPT_CMDMODE() to handle check-term-format and next-all > because these sub commands are independent and error should be shown if > used together and should be handled independently.
As is often the case, after some discussion a single patch becomes more than just one change. This is what we see here, too: OPT_CMDMODE() is a change that needs preparation of the existing code in builtin/bisect--helper.c, and I would highly suggest to split that change out into its own patch. It makes for a nicer story, and it is *much* easier to review.
> This commit reduces the number of failed tests in > t6030-bisect-porcelain.sh and t6041-bisect-submodule.sh
Oh? Which tests are supposed to fail? I do not see any failing tests here...
Show 11 quoted lines
> diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
> index 3324229..ab3891c 100644
> --- a/builtin/bisect--helper.c
> +++ b/builtin/bisect--helper.c
> [...]
> +static int check_term_format(const char *term, const char *revision, int flag) {
> + if (check_refname_format(term, flag))
> + die("'%s' is not a valid term", term);
> +
> + if (one_of(term, "help", "start", "skip", "next", "reset", "visualize",
> + "replay", "log", "run", NULL))If I understood Junio correctly, he meant to line up the second line with the corresponding level. In this case, as "replay" is a parameter of the one_of() function, the indentation would look like this instead:
if (one_of(term, "help", "start", "skip", "next", "reset", "visualize", "replay", "log", "run", NULL))
Show 7 quoted lines
> + die("can't use the builtin command '%s' as a term", term);
> +
> + /* In theory, nothing prevents swapping
> + * completely good and bad, but this situation
> + * could be confusing and hasn't been tested
> + * enough. Forbid it for now.
> + */I see quite a few comments that put the closing "*/" on its own line, but do not award the same pleasure to the opening "/*". Personally, I much prefer the opening "/*" to have an entire line to itself, too, but I guess that there is enough precendence in Git's source code to accept both forms.
Show 7 quoted lines
> + if (!strcmp(term, "bad") || !strcmp(term, "new"))
> + if (strcmp(revision, "bad"))
> + die("can't change the meaning of term '%s'", term);
> +
> + if(!strcmp(term, "good") || !strcmp(term, "old"))
> + if (strcmp(revision, "good"))
> + die("can't change the meaning of term '%s'", term);I am still convinced that
if ((one_of(term, "bad", "new", NULL) && strcmp(orig_term, "bad")) ||
(one_of(term, "good", "old", NULL) && strcmp(orig_term, "good")))
die("can't change the meaning of term '%s'", term);looks so much nicer.
Show 10 quoted lines
> int cmd_bisect__helper(int argc, const char **argv, const char *prefix)
> {
> - int next_all = 0;
> + int sub_command = 0;
> int no_checkout = 0;
> +
> + enum sub_commands {
> + NEXT_ALL,
> + CHECK_TERM_FMT
> + };Interesting. I did not think that Git's source code declares enums inside functions, but builtin/remote.c's config_read_branches() does, so this code is fine.
Still, the patch would be easier to review (corollary: bugs would have a harder time to hide) if the change from OPT_BOOL to OPT_CMDMODE was done in a separate, preparatory patch.
Show 17 quoted lines
> argc = parse_options(argc, argv, prefix, options,
> git_bisect_helper_usage, 0);
>
> - if (!next_all)
> + if (sub_command == CHECK_TERM_FMT) {
> + if (argc == 2) {
> + if (argv[0] != NULL && argv[1] != NULL)
> + return check_term_format(argv[0], argv[1], 0);
> + else
> + die("no revision or term provided with check_for_term");
> + }
> + else
> + die("--check-term-format expects 2 arguments");
> + }
> +
> + if (sub_command != NEXT_ALL && sub_command != CHECK_TERM_FMT)
> usage_with_options(git_bisect_helper_usage, options);Personally, I would prefer
- the usage_with_options() code to come before any sub_command processing,
- the sub_command enum to be initialized with -1, or alternatively hardcoding NEXT_ALL to 1,
- to avoid else clauses after an if () clause whose block returns or die()s,
- to order the clauses of an if/else in ascending size, i.e.
if (argc != 2) die(...); if ...
- to avoid checking argv[i] for NULL when i < argc (it is the contract that argv[0..argc-1] are all non-NULL, so checking for it is unnecessary churn),
- use a switch() on sub_command instead of unrolled if () statements, and
- wrap the code at 80 columns/row (interpreting tabs as "up to 8 spaces").
The rest of the patch looks good.
Ciao, Johannes