From: "Wolfgang Müller" <wolf@oriole.systems>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC PATCH] rev-parse: fix segfault with missing --path-format argument
Date: Sun, 16 May 2021 16:31:56 +0200 [thread overview]
Message-ID: <20210516143156.mauc2ukryx5j2e2r@nabokov.fritz.box> (raw)
In-Reply-To: <xmqqsg2m6dsi.fsf@gitster.g>
On 2021-05-16 21:53, Junio C Hamano wrote:
> As die() is end-user facing, you'd probably want
>
> die(_("--path-format requires an argument"));
>
> We do have untranslated die() nearby for the same option, which may
> want to be cleaned up either in a preliminary patch, or in this same
> patch as an unrelated fix "while we are at it".
I would not mind preparing a preliminary patch that cleans up all
untranslated user-facing calls to die(). My editor finds 15 of those in
rev-parse.c, and I think they all qualify.
If you'd rather not touch unrelated code paths I'll instead include it
in v2 as an unrelated fix in the same commit.
> The above is certainly worth testing for, but if we ever upgrade the
> command line parser of "rev-parse" to be compatible with the parser
> based on the parse-options API to allow both "--opt=val" and "--opt
> val", it will start to fail for an entirely different reason, namely
> "--show-toplevel" will be taken as the argument to "--path-format",
> and we'd get "unknown argument to --path-format". So it might be
> prudent to test both, i.e.
>
> test_must_fail git rev-parse --path-format --show-toplevel &&
> test_must_fail git rev-parse --show-toplevel --path-format
I think I initially went for "--path-format --show-toplevel" because I
was under the assumption that --path-format needs another option it can
modify. It seems that this is not the case, so wouldn't it be simpler
here to do the following instead:
test_must_fail git rev-parse --path-format
That way we do not have to worry about subsequent changes to other,
unrelated, options.
--
Wolfgang
next prev parent reply other threads:[~2021-05-16 14:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-16 12:04 [RFC PATCH] rev-parse: fix segfault with missing --path-format argument Wolfgang Müller
2021-05-16 12:53 ` Junio C Hamano
2021-05-16 14:31 ` Wolfgang Müller [this message]
2021-05-16 21:59 ` Junio C Hamano
2021-05-17 7:19 ` Wolfgang Müller
2021-05-17 8:02 ` [PATCH v2 0/2] rev-parse: Fix segfault and translate messages Wolfgang Müller
2021-05-17 8:02 ` [PATCH v2 1/2] rev-parse: fix segfault with missing --path-format argument Wolfgang Müller
2021-05-17 8:16 ` Jeff King
2021-05-19 9:52 ` Wolfgang Müller
2021-05-19 10:19 ` Wolfgang Müller
2021-05-19 14:21 ` Jeff King
2021-05-17 8:02 ` [PATCH v2 2/2] rev-parse: Mark die() messages for translation Wolfgang Müller
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210516143156.mauc2ukryx5j2e2r@nabokov.fritz.box \
--to=wolf@oriole.systems \
--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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).