From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com>,
"Matěj Cepl" <mcepl@cepl.eu>,
"Jonas Konrad" <jonas.konrad@uni-muenster.de>,
git@vger.kernel.org
Subject: Re: Git branch outputs usage message on stderr
Date: Wed, 15 Jan 2025 15:32:29 -0800 [thread overview]
Message-ID: <xmqqplknvek2.fsf@gitster.g> (raw)
In-Reply-To: <20250115222728.GA132248@coredump.intra.peff.net> (Jeff King's message of "Wed, 15 Jan 2025 17:27:28 -0500")
Jeff King <peff@peff.net> writes:
> I don't know if we'd want something like this on top. If somebody is
> interested in just doing all the conversions in the near-term, we could
> do without the optional flag.
Ah, you are much more practical than I am ;-) I was wondering if we
want a list of "these commands have already been updated" and behave
differently.
> Currently t0012 is permissive and allows either behavior. We'd like it
> to eventually enforce that help goes to stdout, and teaching it to do so
> identifies the commands that need to be changed. But during the
> transition period, we don't want to enforce that for most test runs.
Yeah, that is why the "git branch -h" thing has been left broken for
such a long time.
> So let's introduce a flag that will let most test runs use the
> permissive behavior, and people interested in converting commands can
> run:
>
> GIT_TEST_HELP_MUST_BE_STDOUT=1 ./t0012-help.sh
>
> to see the failures. Eventually (when all builtins have been converted)
> we'll remove this flag entirely and always check the strict behavior.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> t/t0012-help.sh | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
Nice.
It is a tangent, but I wonder how many among the 40 really needed to
use usage_with_options() to react to "-h" in the first place. In
other words, these manual checks for "-h" are done only because the
code _wants_ to react to "-h" before it calls parse_options(), but
does everybody who _wants_ to do so really _needs_ to do so? You
already have shown that "gir branch" did not have to, and to me, 40
among 100+ felt way too many.
> diff --git a/t/t0012-help.sh b/t/t0012-help.sh
> index 1d273d91c2..9c7ae9fd36 100755
> --- a/t/t0012-help.sh
> +++ b/t/t0012-help.sh
> @@ -255,9 +255,16 @@ do
> (
> GIT_CEILING_DIRECTORIES=$(pwd) &&
> export GIT_CEILING_DIRECTORIES &&
> - test_expect_code 129 git -C sub $builtin -h >output 2>&1
> + test_expect_code 129 git -C sub $builtin -h >output 2>err
> ) &&
> - test_grep usage output
> + if test -n "$GIT_TEST_HELP_MUST_BE_STDOUT"
> + then
> + test_must_be_empty err &&
This may be a bit stricter than needed (things other than usage may
need to be spitted out), but it is sufficent to declare that we will
deal with any potential fallout only after it becomes necessary ;-).
> + test_grep usage output
> + else
> + test_grep usage output ||
> + test_grep usage err
> + fi
> '
> done <builtins
Will queue. Thanks.
next prev parent reply other threads:[~2025-01-15 23:32 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-15 11:21 Git branch outputs usage message on stderr Jonas Konrad
2025-01-15 11:36 ` Matěj Cepl
2025-01-15 14:47 ` Jonas Konrad
2025-01-15 15:28 ` Junio C Hamano
2025-01-15 16:55 ` Kristoffer Haugsbakk
2025-01-15 17:14 ` Jeff King
2025-01-15 17:49 ` Junio C Hamano
2025-01-15 17:56 ` Junio C Hamano
2025-01-15 18:24 ` Jeff King
2025-01-15 21:16 ` Junio C Hamano
2025-01-15 21:29 ` Jeff King
2025-01-15 21:56 ` Junio C Hamano
2025-01-15 22:27 ` Jeff King
2025-01-15 23:32 ` Junio C Hamano [this message]
2025-01-16 1:21 ` Junio C Hamano
2025-01-16 10:24 ` Jeff King
2025-01-15 22:11 ` Junio C Hamano
2025-01-15 22:28 ` Jeff King
2025-01-15 23:35 ` Junio C Hamano
2025-01-15 18:29 ` Junio C Hamano
2025-01-15 18:33 ` Kristoffer Haugsbakk
2025-01-15 21:13 ` Junio C Hamano
2025-01-15 17:14 ` Jonas Konrad
2025-01-15 17:53 ` Kristoffer Haugsbakk
2025-01-15 17:19 ` Junio C Hamano
2025-01-15 17:39 ` Kristoffer Haugsbakk
2025-01-15 17:47 ` 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=xmqqplknvek2.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jonas.konrad@uni-muenster.de \
--cc=kristofferhaugsbakk@fastmail.com \
--cc=mcepl@cepl.eu \
--cc=peff@peff.net \
/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).