From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: Eric Sunshine <sunshine@sunshineco.com>,
cousteau via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org,
Javier Mora <cousteaulecommandant@gmail.com>
Subject: Re: [PATCH] doc/git-bisect: clarify `git bisect run` syntax
Date: Mon, 23 Oct 2023 10:23:55 -0700 [thread overview]
Message-ID: <xmqqsf61ntg4.fsf@gitster.g> (raw)
In-Reply-To: <ZTYi55w_70ZlP8Ew@tanuki> (Patrick Steinhardt's message of "Mon, 23 Oct 2023 09:38:15 +0200")
Patrick Steinhardt <ps@pks.im> writes:
>> I also thought at least some commands we know the "-h" output and
>> SYNOPSIS match, we had tests to ensure they do not drift apart. We
>> would probably want to cover more subcommands with t0450.
>>
>> Thanks.
>
> If we don't want them to drift apart I wonder whether we could instead
> generate the synopsis from the output of `-h`? This reduces duplication
> at the cost of a more complex build process for our manpages.
There also is the cost of making it unusable to peek the source
git-foo.txt files as a quick way to get the usage guide, which I
think is a downside only felt by developers of Git (not developers
of other projects that happen to use Git), but still a downside.
But aside from that, it is an obviously possible direction to go [*]
and in fact I suspect we may have talked about it when Ævar made a
gigantic effort to clean these up in Sep-Oct 2022 timeframe, which
resulted in the series leading to a0343f30 (tests: assert consistent
whitespace in -h output, 2022-10-13) [*].
[Footnote]
* And another possibility is to go from the doc to the message
string, which may be even more involved, but at least the code
needs to go through the build process anyway, so the downside
might be lessor)
* https://lore.kernel.org/git/patch-v5-34.34-4de83d3d89a-20221013T153626Z-avarab@gmail.com/
next prev parent reply other threads:[~2023-10-23 17:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-22 20:02 [PATCH] doc/git-bisect: clarify `git bisect run` syntax cousteau via GitGitGadget
2023-10-22 21:32 ` Eric Sunshine
2023-10-23 0:35 ` Junio C Hamano
2023-10-23 7:38 ` Patrick Steinhardt
2023-10-23 16:27 ` Javier Mora
2023-10-23 17:46 ` Junio C Hamano
2023-10-23 17:23 ` Junio C Hamano [this message]
2023-10-23 19:23 ` [PATCH v2] " cousteau via GitGitGadget
2023-10-23 19:36 ` Eric Sunshine
2023-10-23 22:53 ` Javier Mora
2023-10-23 23:18 ` Eric Sunshine
2023-10-24 0:12 ` 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=xmqqsf61ntg4.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=cousteaulecommandant@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=ps@pks.im \
--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.
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 NNTP newsgroup(s).