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

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