git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: George Espinoza <gespinoz2019@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: george espinoza via GitGitGadget <gitgitgadget@gmail.com>,
	Git List <git@vger.kernel.org>
Subject: Re: [PATCH 2/6] [Outreachy] check-ref-format: parse-options
Date: Fri, 8 Nov 2019 23:42:21 -0800	[thread overview]
Message-ID: <CAP_ANin4=ES8PRo=dnPTzyq+BPwqfGGwBkWJzSndfHUk+J1ASg@mail.gmail.com> (raw)
In-Reply-To: <xmqqmud8ouf2.fsf@gitster-ct.c.googlers.com>

On Thu, Nov 7, 2019 at 2:25 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> "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 ;-)
>

Ah, I see. I will use capital letters.
> > 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().

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!

  reply	other threads:[~2019-11-09  7:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-07  8:09 [PATCH 0/6] [Outreachy] check-ref-format: parse-options George Espinoza via GitGitGadget
2019-11-07  8:09 ` [PATCH 1/6] [Outreachy] merge-ours: include parse-option.h george espinoza via GitGitGadget
2019-11-07  9:55   ` Junio C Hamano
2019-11-07  8:09 ` [PATCH 2/6] [Outreachy] check-ref-format: parse-options george espinoza via GitGitGadget
2019-11-07 10:25   ` Junio C Hamano
2019-11-09  7:42     ` George Espinoza [this message]
2019-11-07  8:09 ` [PATCH 3/6] This file wasn't supposed to change during my git push for check-ref-format :( george espinoza via GitGitGadget
2019-11-07 10:23   ` Junio C Hamano
2019-11-07  8:09 ` [PATCH 4/6] [Outreachy] check-ref-format: parse options george espinoza via GitGitGadget
2019-11-07  8:09 ` [PATCH 5/6] [Outreachy] check-ref-format: parse-options george espinoza via GitGitGadget
2019-11-07  8:10 ` [PATCH 6/6] " george espinoza via GitGitGadget

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAP_ANin4=ES8PRo=dnPTzyq+BPwqfGGwBkWJzSndfHUk+J1ASg@mail.gmail.com' \
    --to=gespinoz2019@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).