git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Shourya Shukla <shouryashukla.oo@gmail.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: christian.couder@gmail.com, kaartic.sivaraam@gmail.com,
	gitster@pobox.com, liu.denton@gmail.com, git@vger.kernel.org,
	congdanhqx@gmail.com
Subject: Re: [PATCH v2] submodule: port subcommand 'set-branch' from shell to C
Date: Wed, 20 May 2020 17:45:30 +0530	[thread overview]
Message-ID: <20200520121530.GA7992@konoha> (raw)
In-Reply-To: <CAPig+cSKFBFdNXA52f5f0q3SetA2btmkXeqyHNw-qwJ5ECq5mQ@mail.gmail.com>

Hello Eric!

On 19/05 02:57, Eric Sunshine wrote:
> On Tue, May 19, 2020 at 2:27 PM Shourya Shukla
> <shouryashukla.oo@gmail.com> wrote:
> > Convert submodule subcommand 'set-branch' to a builtin. Port 'set-branch'
> > to 'submodule--helper.c' and call the latter via 'git-submodule.sh'.
> 
> You can reduce the redundancy by writing this as:
> 
>     Convert git-submodule subcommand 'set-branch' to a builtin and
>     call it via 'git-submodule.sh'.

Sure! Will do!

> > +       struct option options[] = {
> > +               OPT__QUIET(&quiet,
> > +                       N_("suppress output for setting default tracking branch of a submodule")),
> 
> This is unusually verbose for a _short_ description of the option.
> Other commands use simpler descriptions. Perhaps take a hint from the
> git-submodule man page:
> 
>     N("only print error messages")),
> 
> However, the bigger question is: Why is the --quiet option even here?
> None of the code in this function ever consults the 'quiet' variable,
> so its presence seems pointless.

I actually wanted to have *some* use of the `quiet` option and delivered
it in the v1, but after some feedback had to scrap it. You may have a
look here:
https://lore.kernel.org/git/20200513201737.55778-2-shouryashukla.oo@gmail.com/

> Looking at the git-submodule documentation, I see that it is already
> documented as accepted --quiet, so it may make some sense for you to
> accept the option here. However, it might be a good idea either to
> have an in-code comment or a blurb in the commit message explaining
> that this C rewrite accepts the option for backward-compatibility (and
> for future extension), not because it is actually used presently.

That seems like a better idea; should I add this comment just above the
`options` array? BTW, the shell version has a comment about this,
see:
https://github.com/git/git/blob/v2.26.2/git-submodule.sh#L727

> > +               OPT_STRING(0, "branch", &opt_branch, N_("branch"),
> > +                       N_("set the default tracking branch to the one specified")),
> 
> Then:
> 
>     N_("set the default tracking branch")),

Seems good!

> > +               OPT_END()
> > +       };
> > +       const char *const usage[] = {
> > +               N_("git submodule--helper set-branch [--quiet] (-d|--default) <path>"),
> > +               N_("git submodule--helper set-branch [--quiet] (-b|--branch) <branch> <path>"),
> > +               NULL
> > +       };
> > +
> > +       argc = parse_options(argc, argv, prefix, options, usage, 0);
> > +
> > +       if (!opt_branch && !opt_default)
> > +               die(_("at least one of --branch and --default required"));
> 
> This wording makes no sense considering that --branch and --default
> are mutually exclusive. By writing "at least one of", you're saying
> that you can use _more than one_, which is clearly incorrect. Reword
> it like this:
> 
>     die(_("--branch or --default required"));

Yeah, I did not realize it until you mentioned this, will correct in the
next version.

> > +       if (opt_branch && opt_default)
> > +               die(_("--branch and --default do not make sense together"));
> 
> A more precise way to say this is:
> 
>     die(_("--branch and --default are mutually exclusive"));

Will that be clear to everyone? What I mean is maybe a person from a
non-mathematical background (someone doing programming as a hobby maybe)
will not grasp at this at one go and will have to search it's meaning
online. Isn't it fine as-is?

> > +       if (argc != 1 || !(path = argv[0]))
> > +               usage_with_options(usage, options);
> > +
> > +       config_name = xstrfmt("submodule.%s.branch", path);
> > +       config_set_in_gitmodules_file_gently(config_name, opt_branch);
> 
> Tracing through the config code, I see that
> config_set_in_gitmodules_file_gently() removes the key if 'opt_branch'
> is NULL, which mirrors the behavior of the shell code this is
> replacing. Good.

Thanks! :)

Regards,
Shourya Shukla

  reply	other threads:[~2020-05-20 12:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19 18:26 [PATCH v2] submodule: port subcommand 'set-branch' from shell to C Shourya Shukla
2020-05-19 18:57 ` Eric Sunshine
2020-05-20 12:15   ` Shourya Shukla [this message]
2020-05-20 13:12     ` Kaartic Sivaraam
2020-05-20 14:37       ` Junio C Hamano
2020-05-20 14:45     ` Eric Sunshine

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=20200520121530.GA7992@konoha \
    --to=shouryashukla.oo@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=congdanhqx@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=kaartic.sivaraam@gmail.com \
    --cc=liu.denton@gmail.com \
    --cc=sunshine@sunshineco.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).