git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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/



  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).