Re: [ANNOUNCE] Git v2.22.0-rc1

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

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.

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.