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.
next prev parent 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.