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

[Junio C Hamano <gitster@pobox.com>]

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

> 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 ;-)

> 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().

> @@ -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.

> -	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.