On Thu, Nov 7, 2019 at 2:25 AM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> "george espinoza via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
>
> > From: george espinoza <gespinoz2019@xxxxxxxxx>
> >
> > 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@xxxxxxxxxx>
> > Helped by: johannes schindelin <johannes.schindelin@xxxxxx>
>
> 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 ;-)
>
Ah, I see. I will use capital letters.
> > Signed-off-by: george espinoza <gespinoz2019@xxxxxxxxx>
> > ---
> > 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().
I see, I will look into doing something more here as necessary.
>
> > @@ -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.
I meant to squash all my earlier commits but had an issue with git rebase -i.
It only says noop. I had an issue when I first started my other branch
and might of reset it. I'll look into fixing this before submitting my
next patch.
>
> > - 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.
Ok I will look into another data structure to use for branch.
>
> 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.
>
I had only intended /submit to show the last commit I had made that had passed
all the tests. I will review everything and only submit again once im 100%
sure everything is in order. Sorry Junio!
