From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v1 1/4] refs: avoid "too many arguments"
Date: Tue, 6 Aug 2024 08:13:23 +0200 [thread overview]
Message-ID: <ZrG_A3UQk56aYJ_m@tanuki> (raw)
In-Reply-To: <20240806003539.3292562-2-gitster@pobox.com>
[-- Attachment #1: Type: text/plain, Size: 1291 bytes --]
On Mon, Aug 05, 2024 at 05:35:36PM -0700, Junio C Hamano wrote:
> diff --git a/t/t1460-refs-migrate.sh b/t/t1460-refs-migrate.sh
> index f7c0783d30..b32e740001 100755
> --- a/t/t1460-refs-migrate.sh
> +++ b/t/t1460-refs-migrate.sh
> @@ -31,9 +31,10 @@ test_expect_success "superfluous arguments" '
> test_when_finished "rm -rf repo" &&
> git init repo &&
> test_must_fail git -C repo refs migrate foo 2>err &&
> - cat >expect <<-EOF &&
> - usage: too many arguments
> - EOF
> + {
> + printf "fatal: unknown argument: ${SQ}foo${SQ}\n\n" &&
> + ( git -C repo refs migrate -h || : )
> + } >expect &&
I always have to wonder how helpful it really is to print the usage
information in such a context. I feel that it is too distracting because
in many cases, we end up printing dozens of lines of options that drown
out the single line of information that the user actually cares for,
namely why the command has failed.
In this case here it is somewhat manageable, because only 4/5th of the
output are unnecessary noise. But the picture changes as commands grow
more options over time, making the output less and less usable.
So while I think that it is a big improvement to explicitly point out
the unknown argument, I think it is step backwards to also print the
usage info.
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-08-06 6:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-06 0:35 [PATCH v1 0/4] make "too many arguments" a bit more useful Junio C Hamano
2024-08-06 0:35 ` [PATCH v1 1/4] refs: avoid "too many arguments" Junio C Hamano
2024-08-06 6:13 ` Patrick Steinhardt [this message]
2024-08-06 16:48 ` Junio C Hamano
2024-08-06 17:11 ` [RFC] usage_msg_opt() and _optf() must die Junio C Hamano
2024-08-06 17:38 ` Eric Sunshine
2024-08-06 20:21 ` Junio C Hamano
2024-08-07 5:01 ` Patrick Steinhardt
2024-08-06 19:09 ` Justin Tobler
2024-08-06 19:24 ` Martin Ågren
2024-08-06 17:47 ` [PATCH v2] refs: avoid "too many arguments" Junio C Hamano
2024-08-06 0:35 ` [PATCH v1 2/4] cat-file: " Junio C Hamano
2024-08-06 0:35 ` [PATCH v1 3/4] notes: " Junio C Hamano
2024-08-06 0:35 ` [PATCH v1 4/4] miscellaneous: " Junio C Hamano
2024-08-06 2:31 ` Eric Sunshine
2024-08-06 16: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=ZrG_A3UQk56aYJ_m@tanuki \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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).