git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Garrit Franke <garrit@slashdev.space>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	git@vger.kernel.org, "Taylor Blau" <ttaylorr@github.com>
Subject: Re: [PATCH v2] cli: add -v and -h shorthands
Date: Thu, 31 Mar 2022 13:07:40 -0700	[thread overview]
Message-ID: <xmqqsfqx28dv.fsf@gitster.g> (raw)
In-Reply-To: <f3935840-e2a0-953e-0e7c-ac921d414ddc@slashdev.space> (Garrit Franke's message of "Thu, 31 Mar 2022 15:08:12 +0200")

Garrit Franke <garrit@slashdev.space> writes:

> On 31.03.22 02:07, Ævar Arnfjörð Bjarmason wrote:
>
>> I think this is a good trade-off in this case. I.e. -v and -h are
>> commonly understood.
>
> An interesting observation I just made is that curl [0] uses both
> "--verbose" and "--version" on the top level [1][2] including
> shorthands. "-v" corresponds to "verbose", "-V" corresponds to
> "version.
>
> Not that I'm a fan of this clutter, but it's a possible path to go
> down if we actually needed a second shorthand using this letter.

Do you mean you want to use "-V" for version, instead of the "-v"
used in the patch, so that "-v" can be left for "--verbose"?

I am not sure consistency with whom we are aiming for anymore with
that mixed to the proposal X-<.

>  const char git_usage_string[] =
> -	N_("git [--version] [--help] [-C <path>] [-c <name>=<value>]\n"
> +	N_("git [-v | --version] [-h | --help] [-C <path>] [-c <name>=<value>]\n"
>  	   "           [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]\n"
>  	   "           [-p | --paginate | -P | --no-pager] [--no-replace-objects] [--bare]\n"
>  	   "           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]\n"

This is an improvement in that the first line that used to be
unusually shorter now becomes comparable length to other lines ;-)

> @@ -146,7 +146,8 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)
>  		 * commands can be written with "--" prepended
>  		 * to make them look like flags.
>  		 */
> -		if (!strcmp(cmd, "--help") || !strcmp(cmd, "--version"))
> +		if (!strcmp(cmd, "--help") || !strcmp(cmd, "--version") ||
> +		    !strcmp(cmd, "-h") || !strcmp(cmd, "-v"))
>  			break;

OK.

> @@ -893,7 +894,12 @@ int cmd_main(int argc, const char **argv)
>  	handle_options(&argv, &argc, NULL);
>  	if (argc > 0) {
>  		/* translate --help and --version into commands */
> -		skip_prefix(argv[0], "--", &argv[0]);
> +		if (!strcmp("-v", argv[0]))
> +			argv[0] = "version";
> +		else if (!strcmp("-h", argv[0]))
> +			argv[0] = "help";
> +		else
> +			skip_prefix(argv[0], "--", &argv[0]);

I find this unnecessarily hard to read.

    (Side note) A tip for reviewers.  Be suspicious of any change
    that adds new things _in front_ of existing sequence.  Question
    if there is a good justification for it.  If there isn't, see if
    it makes it better if you instead append the new stuff to
    existing sequence.  If neither results in satisfying code,
    perhaps it is good time to totally rewrite it to make both
    existing and new stuff fit in the flow.

The original was in a sense a bit sloppy to strip "--" from anything
that begins with "--", when we only care about "--verbose" and
"--help" and nothing else (granted, handle_options() would barf when
argv[0] begins with "--" and is not one of these two, so the
sloppiness does not make a difference in practice).

If we accept the same kind of sloppiness, perhaps

		if (skip_prefix(argv[0], "--", &argv[0]))
                	; /* removed "--" from "--help" and "--version" */
		else if (argv[0][0] == '-')
                	argv[0] = argv[0][1] == 'v' ? "version" : "help";
                	
would make the new side match the existing one better, but I would
not necessarily recommend it.

We may want to be a bit more explicit and readable, by spelling out
the expectation, i.e.

		if (!strcmp("--version", argv[0]) || !strcmp("-v", argv[0]))
			argv[0] = "version";
		else if (!strcmp("--help", argv[0]) || !strcmp("-h", argv[0]))
			argv[0] = "help"; 

This makes it clear that these two pseudo-commands, spelled with a
dash in front and stand for other commands, are the only thing we
care about and what their accepted spelling are.

Hmm?

  reply	other threads:[~2022-03-31 20:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-30 19:09 [PATCH v2] cli: add -v and -h shorthands Garrit Franke
2022-03-30 21:53 ` Junio C Hamano
2022-03-30 22:50   ` Garrit Franke
2022-03-31  0:07     ` Ævar Arnfjörð Bjarmason
2022-03-31 13:08       ` Garrit Franke
2022-03-31 20:07         ` Junio C Hamano [this message]
2022-04-01  9:23           ` Ævar Arnfjörð Bjarmason
2022-04-01 16:02             ` Junio C Hamano
2022-04-04  7:18               ` Garrit Franke
2022-04-04 16:19                 ` Junio C Hamano
2022-03-31 21:27 ` [PATCH v3] " Garrit Franke

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=xmqqsfqx28dv.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=avarab@gmail.com \
    --cc=garrit@slashdev.space \
    --cc=git@vger.kernel.org \
    --cc=ttaylorr@github.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).