From: Junio C Hamano <gitster@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: git@vger.kernel.org, John Cai <johncai86@gmail.com>
Subject: Re: [PATCH] doc txt & -h consistency: fix recent "cat-file" inconsistency
Date: Thu, 07 Apr 2022 13:27:42 -0700 [thread overview]
Message-ID: <xmqqv8vkr64h.fsf@gitster.g> (raw)
In-Reply-To: <patch-1.1-79404e05d73-20220407T185645Z-avarab@gmail.com> ("Ævar Arnfjörð Bjarmason"'s message of "Thu, 7 Apr 2022 21:08:59 +0200")
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> Subject: Re: [PATCH] doc txt & -h consistency: fix recent "cat-file" inconsistency
IOW ...
> -'git cat-file' (--batch | --batch-check) [--batch-all-objects]
> +'git cat-file' (--batch | --batch-check | --batch-command) [--batch-all-objects]
... we forgot to add "--batch-command" to the documentation, even
though we added it to the usage text in the source.
And explained that way, this change makes quite a lot of sense.
It could be a worthwhile longer-term goal to make it consistent
between the synopsis and the usage text", but we are far away from
such a goal. I'd rather keep such a topic outside this focused fix.
Given that we have been pushing to stop listing individual options
in SYNOPSIS, and instead using <option> placeholder, and also list
different operation mode of a single command on separate lines,
between
$ git commit -h 2>&1 | sed -e '/^$/q'
$ git commit --help | sed -ne '/^SYNOPSIS/,/^$/p'
we would want to pick the one we have from the command (i.e. the
former) and update the documentation source for the latter.
Side note: and no, we do not want to tie the documentation to a
particular build too tightly, and it is a no-no to generate the
documentation source from 'git cmd -h' output. Even when an
option is conditionally excluded from a particular build, I'd
like to be able to build and publish documentation for wider
audience than just to myself.
Somebody needs to go through the comparison of individual
subcommands and present a good plan. I find that, in comparison
between the -h and --help output, neither is quite satisfactory for
"git bisect", for example. It would be a huge task and would be a
distraction during the pre-release period.
Thanks.
next prev parent reply other threads:[~2022-04-07 20:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-07 19:08 [PATCH] doc txt & -h consistency: fix recent "cat-file" inconsistency Ævar Arnfjörð Bjarmason
2022-04-07 20:27 ` Junio C Hamano [this message]
2022-04-08 8:55 ` Ævar Arnfjörð Bjarmason
2022-04-08 18:33 ` 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=xmqqv8vkr64h.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=johncai86@gmail.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).