Re: [PATCH 2/6] [Outreachy] check-ref-format: parse-options

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 7, 2019, 10:25 UTC
Message-ID: <xmqqmud8ouf2.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <e8bca0910e7ba7582a50115eeeb66406d965a52a.1573114201.git.gitgitgadget@gmail.com>

"george espinoza via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 18 quoted lines

> From: george espinoza <gespinoz2019@gmail.com>
>
> This command currently handles its own argv so by teaching it to
> use parse-options instead we can standardize the way commands
> handle user input across the project.
>
> As a consequence of using OPT_BOOL data structure on --normalize &
> --refspec-pattern, --no-normalize & --no-refspec-pattern has been
> can now be used.
>
> NO_PARSEOPT flag was also removed to update git.c with the
> conversion of the structure in this command.
>
> This is a rough draft and I need some advice if I'm doing this
> correctly since its being built but it is failing tests.
>
> Helped by: emily shaffer <emilyshaffer@google.com>
> Helped by: johannes schindelin <johannes.schindelin@gmx.de>

I do not think they spell their name like the above. In general, most of us do not spell our names in all lowercase around here. I appreciate people with originality, but I'd rather see them to be original not in how they spell their names but in more productive ways ;-)

Show 24 quoted lines

> Signed-off-by: george espinoza <gespinoz2019@gmail.com>
> ---
>  builtin/check-ref-format.c | 49 +++++++++++++++++++-------------------
>  git.c                      |  2 +-
>  2 files changed, 26 insertions(+), 25 deletions(-)
>
> diff --git a/builtin/check-ref-format.c b/builtin/check-ref-format.c
> index bc67d3f0a8..3fe0b5410a 100644
> --- a/builtin/check-ref-format.c
> +++ b/builtin/check-ref-format.c
> @@ -6,10 +6,13 @@
>  #include "refs.h"
>  #include "builtin.h"
>  #include "strbuf.h"
> +#include "parse-options.h"
>  
> -static const char builtin_check_ref_format_usage[] =
> -"git check-ref-format [--normalize] [<options>] <refname>\n"
> -"   or: git check-ref-format --branch <branchname-shorthand>";
> +static const char * const builtin_check_ref_format_usage[] = {
> +	N_("git check-ref-format [--normalize] [<options>] <refname>\n"),
> +	N_("   or: git check-ref-format --branch <branchname-shorthand>"),
> +	NULL,
> +};

OK.  This is the bog-standard prep for calling usage_with_options().

Show 17 quoted lines

> @@ -53,31 +56,29 @@ static int check_ref_format_branch(const char *arg)
>  
>  int cmd_check_ref_format(int argc, const char **argv, const char *prefix)
>  {
> -	int i;
> -	int normalize = 0;
> +	enum {
> +		CHECK_REF_FORMAT_BRANCH,
> +	};
> +
> +	int i = 0;
> +	int verbose;
> +	int normalize;
> +	int allow_onelevel;
> +	int refspec_pattern;
>  	int flags = 0;
>  	const char *refname;

Discard the blank line before "int i = 0" line, and keep the blank line you have here between the last declaration and the first statement.

Show 9 quoted lines

> -	if (argc == 2 && !strcmp(argv[1], "-h"))
> -		usage(builtin_check_ref_format_usage);
> -
> -	if (argc == 3 && !strcmp(argv[1], "--branch"))
> -		return check_ref_format_branch(argv[2]);
> +	struct option options[] = {
> +		OPT__VERBOSE(&verbose, N_("be verbose")),
> +		OPT_GROUP(""),
> +		OPT_CMDMODE( 0 , "branch", &check_ref_format_branch, N_("branch"), CHECK_REF_FORMAT_BRANCH),

This is an iffy/tricky way to use CMDMODE. The way CMDMODE is designed to be used is to have multiple ones that sets the same target variable so that parse_options() can notice conflicting command line request that gives more than one from the same set.

The command has two modes (i.e. the "--branch" mode and the unnamed mode), so it is understandable that there is only one CMDMODE in the options[] array, but I am not sure how well it would work for a command like this. For example, "check-ref-format --branch --normalize --allow-onelevel $v" should error out because --branch is not compatible with any other options. I do not think a single parse_options() call with a single options[] array can express that kind of constraints.

Besides, shouldn't the third parameter of OPT_CMDMODE supposed to be the address of the variable that would receive the value in its fifth parameter? I do not see a decl for check_ref_format_branch variable (isn't that the name of the function???).

Ahh, you said it builds but does not pass test. Of course, that is because this part is completely bogus.

It appears that to your series the only thing that matters is the shape of the tree after applying all of the patches, and individual steps are not ready to be reviewd, so I'd stop here.