From: Junio C Hamano <gitster@pobox.com>
To: Simon Ruderich <simon@ruderich.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Git Mailing List <git@vger.kernel.org>,
Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>
Subject: Re: Silly "git gc" UI issue.
Date: Sat, 21 Apr 2018 12:13:13 +0900 [thread overview]
Message-ID: <xmqqlgdhb6ba.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20180420072701.GB13462@ruderich.org> (Simon Ruderich's message of "Fri, 20 Apr 2018 09:27:01 +0200")
Simon Ruderich <simon@ruderich.org> writes:
> On Thu, Apr 19, 2018 at 02:10:40PM +0900, Junio C Hamano wrote:
>> diff --git a/parse-options-cb.c b/parse-options-cb.c
>> index c6679cb2cd..872627eafe 100644
>> --- a/parse-options-cb.c
>> +++ b/parse-options-cb.c
>> @@ -38,7 +38,11 @@ int parse_opt_approxidate_cb(const struct option *opt, const char *arg,
>> int parse_opt_expiry_date_cb(const struct option *opt, const char *arg,
>> int unset)
>> {
>> - return parse_expiry_date(arg, (timestamp_t *)opt->value);
>> + if (unset)
>> + arg = "never";
>> + if (parse_expiry_date(arg, (timestamp_t *)opt->value))
>> + die("malformed expiration date '%s'", arg);
>> + return 0;
>> }
>
> Should this error get translated?
Sure. The new test to check this codepath even protects itself from
such a translation by using test_i18ngrep, so this is safe to mark
for translation from day one.
Thanks.
-- >8 --
Subject: [PATCH v2] parseopt: handle malformed --expire arguments more nicely
A few commands that parse --expire=<time> command line option behave
sillily when given nonsense input. For example
$ git prune --no-expire
Segmentation falut
$ git prune --expire=npw; echo $?
129
Both come from parse_opt_expiry_date_cb().
The former is because the function is not prepared to see arg==NULL
(for "--no-expire", it is a norm; "--expire" at the end of the
command line could be made to pass NULL, if it is told that the
argument is optional, but we don't so we do not have to worry about
that case).
The latter is because it does not check the value returned from the
underlying parse_expiry_date().
This seems to be a recent regression introduced while we attempted
to avoid spewing the entire usage message when given a correct
option but with an invalid value at 3bb0923f ("parse-options: do not
show usage upon invalid option value", 2018-03-22). Before that, we
didn't fail silently but showed a full usage help (which arguably is
not all that better).
Also catch this error early when "git gc --prune=<expiration>" is
misspelled by doing a dummy parsing before the main body of "gc"
that is time consuming even begins. Otherwise, we'd spend time to
pack objects and then later have "git prune" first notice the error.
Aborting "gc" in the middle that way is not harmful but is ugly and
can be avoided.
Helped-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* marking the new message in parse_opt_expiry_date_cb() function
for i18n is the only change from the previous round.
builtin/gc.c | 4 ++++
parse-options-cb.c | 6 +++++-
t/t5304-prune.sh | 10 ++++++++++
3 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/builtin/gc.c b/builtin/gc.c
index 3c5eae0edf..858aa444e1 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -353,6 +353,7 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
const char *name;
pid_t pid;
int daemonized = 0;
+ timestamp_t dummy;
struct option builtin_gc_options[] = {
OPT__QUIET(&quiet, N_("suppress progress reporting")),
@@ -388,6 +389,9 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
if (argc > 0)
usage_with_options(builtin_gc_usage, builtin_gc_options);
+ if (prune_expire && parse_expiry_date(prune_expire, &dummy))
+ die(_("Failed to parse prune expiry value %s"), prune_expire);
+
if (aggressive) {
argv_array_push(&repack, "-f");
if (aggressive_depth > 0)
diff --git a/parse-options-cb.c b/parse-options-cb.c
index c6679cb2cd..0f9f311a7a 100644
--- a/parse-options-cb.c
+++ b/parse-options-cb.c
@@ -38,7 +38,11 @@ int parse_opt_approxidate_cb(const struct option *opt, const char *arg,
int parse_opt_expiry_date_cb(const struct option *opt, const char *arg,
int unset)
{
- return parse_expiry_date(arg, (timestamp_t *)opt->value);
+ if (unset)
+ arg = "never";
+ if (parse_expiry_date(arg, (timestamp_t *)opt->value))
+ die(_("malformed expiration date '%s'"), arg);
+ return 0;
}
int parse_opt_color_flag_cb(const struct option *opt, const char *arg,
diff --git a/t/t5304-prune.sh b/t/t5304-prune.sh
index 6694c19a1e..af69cdc112 100755
--- a/t/t5304-prune.sh
+++ b/t/t5304-prune.sh
@@ -320,4 +320,14 @@ test_expect_success 'prune: handle HEAD reflog in multiple worktrees' '
test_cmp expected actual
'
+test_expect_success 'prune: handle expire option correctly' '
+ test_must_fail git prune --expire 2>error &&
+ test_i18ngrep "requires a value" error &&
+
+ test_must_fail git prune --expire=nyah 2>error &&
+ test_i18ngrep "malformed expiration" error &&
+
+ git prune --no-expire
+'
+
test_done
next prev parent reply other threads:[~2018-04-21 3:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-19 1:45 Silly "git gc" UI issue Linus Torvalds
2018-04-19 1:52 ` Junio C Hamano
2018-04-19 1:55 ` Junio C Hamano
2018-04-19 2:16 ` Junio C Hamano
2018-04-19 2:29 ` Linus Torvalds
2018-04-19 3:22 ` Junio C Hamano
2018-04-19 5:10 ` Junio C Hamano
2018-04-20 7:27 ` Simon Ruderich
2018-04-21 3:13 ` Junio C Hamano [this message]
2018-04-21 6:07 ` Christian Couder
2018-04-23 13:38 ` Junio C Hamano
2018-04-19 2:19 ` Linus Torvalds
2018-04-19 10:34 ` Simon Ruderich
2018-04-20 0:14 ` 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=xmqqlgdhb6ba.fsf@gitster-ct.c.googlers.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=simon@ruderich.org \
--cc=torvalds@linux-foundation.org \
--cc=ungureanupaulsebastian@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).