All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Jean-Noël Avila via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, "Jean-Noël Avila" <jn.avila@free.fr>
Subject: Re: [PATCH 1/3] doc: git-rev-parse: enforce command-line description syntax
Date: Tue, 20 Feb 2024 14:57:12 -0800	[thread overview]
Message-ID: <xmqqsf1mlp6f.fsf@gitster.g> (raw)
In-Reply-To: <17b0284c379e62a756e1bba008f4671f6afc0ad9.1708468374.git.gitgitgadget@gmail.com> ("Jean-Noël Avila via GitGitGadget"'s message of "Tue, 20 Feb 2024 22:32:52 +0000")

"Jean-Noël Avila via GitGitGadget" <gitgitgadget@gmail.com> writes:

>  [verse]
> -'git rev-parse' [<options>] <args>...
> +'git rev-parse' [<options>] <arg>...

Good.  The "or more" is signalled by the ellipsis, not "args" being
plural.

> ---short[=length]::
> +--short[=<length>]::
>  	Same as `--verify` but shortens the object name to a unique
>  	prefix with at least `length` characters. The minimum length

This same comment applies throughout this patch, but in other places
when we use <placeholder> in the option argument description, don't
we use the same <placeholder> in text as well?  I am wondering if
the `length` (typeset in fixed-width) should become <length>.  What
do other recent[*] documentation pages commonly do?

	Side note: I say "recent" because rev-parse doc is one of
	the oldest ones that did not get typesetting attention they
	deserve, compared to more recent ones that got nitpicked
	while they were written and updated.

> ---branches[=pattern]::
> ---tags[=pattern]::
> ---remotes[=pattern]::
> +--branches[=<pattern>]::
> +--tags[=<pattern>]::
> +--remotes[=<pattern>]::
>  	Show all branches, tags, or remote-tracking branches,
>  	respectively (i.e., refs found in `refs/heads`,
>  	`refs/tags`, or `refs/remotes`, respectively).

Ditto.  We see `pattern` that may want to become <pattern> in the
description (after the post context of this hunk).

> ---glob=pattern::
> +--glob=<pattern>::
>  	Show all refs matching the shell glob pattern `pattern`. If
>  	the pattern does not start with `refs/`, this is automatically
>  	prepended.  If the pattern does not contain a globbing

Ditto.

> ---exclude-hidden=[fetch|receive|uploadpack]::
> +--exclude-hidden=(fetch|receive|uploadpack)::
>  	Do not include refs that would be hidden by `git-fetch`,
>  	`git-receive-pack` or `git-upload-pack` by consulting the appropriate
>  	`fetch.hideRefs`, `receive.hideRefs` or `uploadpack.hideRefs`

Good.

> ---since=datestring::
> ---after=datestring::
> +--since=<datestring>::
> +--after=<datestring>::
>  	Parse the date string, and output the corresponding
>  	--max-age= parameter for 'git rev-list'.

Good, modulo possibly "date string" -> "<datestring>".

> ---until=datestring::
> ---before=datestring::
> +--until=<datestring>::
> +--before=<datestring>::
>  	Parse the date string, and output the corresponding
>  	--min-age= parameter for 'git rev-list'.

Ditto.

> -<args>...::
> +<arg>...::
>  	Flags and parameters to be parsed.

Good.

  reply	other threads:[~2024-02-20 22:57 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-20 22:32 [PATCH 0/3] Doc placeholders Jean-Noël Avila via GitGitGadget
2024-02-20 22:32 ` [PATCH 1/3] doc: git-rev-parse: enforce command-line description syntax Jean-Noël Avila via GitGitGadget
2024-02-20 22:57   ` Junio C Hamano [this message]
2024-02-21  7:41     ` Jean-Noël Avila
2024-02-21 17:31       ` Junio C Hamano
2024-02-21 21:52         ` Jean-Noël AVILA
2024-02-21 22:36         ` Junio C Hamano
2024-02-22  9:07           ` Jean-Noël AVILA
2024-02-22 16:38             ` Junio C Hamano
2024-02-24 18:28               ` Jean-Noël AVILA
2024-02-20 22:32 ` [PATCH 2/3] doc: git-clone fix missing placeholder end carret Jean-Noël Avila via GitGitGadget
2024-02-20 22:39   ` Eric Sunshine
2024-02-20 23:01     ` Junio C Hamano
2024-02-20 22:32 ` [PATCH 3/3] doc: add some missing sentence dots Jean-Noël Avila via GitGitGadget
2024-02-20 22:50   ` Junio C Hamano

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

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

  git send-email \
    --in-reply-to=xmqqsf1mlp6f.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=jn.avila@free.fr \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.