git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Duy Nguyen <pclouds@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Bryan Turner <bturner@atlassian.com>,
	Junio C Hamano <gitster@pobox.com>,
	Git Users <git@vger.kernel.org>
Subject: Re: [ANNOUNCE] Git v2.22.0-rc1
Date: Tue, 21 May 2019 18:46:21 +0700	[thread overview]
Message-ID: <CACsJy8CfGnZgn1VjaEQYeRRa3BOT9vqcp73RcVbjHBOw3R1vMQ@mail.gmail.com> (raw)
In-Reply-To: <87blzwuk1t.fsf@evledraar.gmail.com>

On Tue, May 21, 2019 at 6:24 PM Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
>
>
> On Tue, May 21 2019, Duy Nguyen wrote:
>
> > (dropping lkml and git-packagers)
> >
> > On Tue, May 21, 2019 at 3:31 PM Duy Nguyen <pclouds@gmail.com> wrote:
> >> > The bug there is that the old opt_arg() code would be torelant to empty
> >> > values. I noticed a similar change the other day with the --abbrev
> >> > option, but didn't think it was worth noting. Maybe it's a more general
> >> > problem, in both cases we had a blindspot in our tests.
> >>
> >> Hmm.. this one is different (at least it does not use opt_arg()). But
> >> I'll double check.
> >
> > What is wrong with --abbrev? The code is simple enough for me to just
> > compare line by line, and the only difference I can see is that if you
> > pass --abbrev=12a, then the old code accepts "12" while the new one
> > rejects.
> >
> > Granted, I said "no behavior change", but this may be pushing the
> > limits a bit. But maybe you're seeing something else?
> >
> > Note that "git diff --abbrev" still uses the old, but different,
> > parser in revision.c. parse_options() is only used for --abbrev with
> > --no-index.
>
> Before d877418390 ("diff-parseopt: convert --[no-]abbrev", 2019-03-24):
>
>     $ ~/g/git/git --exec-path=$PWD diff --raw --abbrev= --no-index {color,column}.c
>     :100644 100644 00000 00000 M    color.c
>
> after:
>
>     $ ~/g/git/git --exec-path=$PWD diff --raw --abbrev= --no-index {color,column}.c
>     :100644 100644 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 M      color.c
>
> This patch brings back the old behavior, but will break tests for
> describe/branch (we have no tests on this for the diff behavior, but I'm
> hoping to re-submit those after 2.22):
>
>     diff --git a/parse-options-cb.c b/parse-options-cb.c
>     index 6e2e8d6273..0a3c8bd565 100644
>     --- a/parse-options-cb.c
>     +++ b/parse-options-cb.c
>     @@ -23 +23 @@ int parse_opt_abbrev_cb(const struct option *opt, const char *arg, int unset)
>     -               if (v && v < MINIMUM_ABBREV)
>     +               if (v < MINIMUM_ABBREV)
>
> I discovered this the other day because I was rebasing my "relative
> abbrev" series and some of the tests I'd added here failed:
> https://public-inbox.org/git/20180608224136.20220-5-avarab@gmail.com/
>
> Now, in that case I think the change is fine, and is what we should do,
> and when I found this I couldn't imagine anyone relied on this
> empty-value '--abbrev=' behavior so I didn't bother to send an E-Mail
> about it. It also brought diff.c in line with what we did with
> empty-value '--abbrev=' elsewhere.

OK.

> I'm just noting it because it might be indicative of some logic errors
> in this conversion for other options, e.g. argument-less -U, and since
> we didn't test for (or --abbrev=) perhaps we have other blind spots.
> such a case.
>
> Unrelated to any potential bugs in yoeur changes, I just noticed that we
> should probably do this too:
>
>     diff --git a/parse-options-cb.c b/parse-options-cb.c
>     index 4b95d04a37..1216a71f4b 100644
>     --- a/parse-options-cb.c
>     +++ b/parse-options-cb.c
>     @@ -16,6 +16,9 @@ int parse_opt_abbrev_cb(const struct option *opt, const char *arg, int unset)
>             if (!arg) {
>                     v = unset ? 0 : DEFAULT_ABBREV;
>             } else {
>     +               if (!*arg)
>     +                       return error(_("option `%s' expects a value"),
>     +                                    opt->long_name);
>                     v = strtol(arg, (char **)&arg, 10);
>                     if (*arg)
>                             return error(_("option `%s' expects a numerical value"),
>
> I.e. we support and document --abbrev=0, but now we conflate it with
> --abbrev= for no good reason.

This is funny because the old --inter-hunk-context= (no argument)
would error out but the new one does not, and I'm making a change to
make all OPT_INTEGER (which is also the new --inter-hunk-context) to
error out to avoid regression. I'm not sure if we should do the same
for --abbrev now, but since we're already half way there, I'll include
this too and see how people react.
-- 
Duy

  reply	other threads:[~2019-05-21 11:46 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-19  9:04 Junio C Hamano
2019-05-19 20:30 ` Johannes Schindelin
2019-05-20 19:06 ` Bryan Turner
2019-05-20 22:27   ` Ævar Arnfjörð Bjarmason
2019-05-21  8:31     ` Duy Nguyen
2019-05-21 10:22       ` Duy Nguyen
2019-05-21 11:24         ` Ævar Arnfjörð Bjarmason
2019-05-21 11:46           ` Duy Nguyen [this message]
2019-05-23 15:04 ` New diff test failures on s390x architecture (was: [ANNOUNCE] Git v2.22.0-rc1) Todd Zullinger
2019-05-23 19:14   ` Todd Zullinger
2019-05-23 20:30     ` Duy Nguyen
2019-05-23 21:06       ` Todd Zullinger

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=CACsJy8CfGnZgn1VjaEQYeRRa3BOT9vqcp73RcVbjHBOw3R1vMQ@mail.gmail.com \
    --to=pclouds@gmail.com \
    --cc=avarab@gmail.com \
    --cc=bturner@atlassian.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --subject='Re: [ANNOUNCE] Git v2.22.0-rc1' \
    /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

Code repositories for project(s) associated with this 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).