Re: [PATCH v2 8/8] tests: disallow the use of abbreviated options (by default)
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Apr 17, 2019, 12:07 UTC
- Message-ID
- <nycvar.QRO.7.76.6.1904171354270.46@tvgsbejvaqbjf.bet>
- In-Reply-To
- <xmqqef63qt5e.fsf@gitster-ct.c.googlers.com>
Hi Junio,
On Mon, 15 Apr 2019, Junio C Hamano wrote:
Show 42 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Mon, 15 Apr 2019, Junio C Hamano wrote:
> >
> >> Junio C Hamano <gitster@pobox.com> writes:
> >>
> >>
> >> > Do you mean more like
> >> > ...
> >> > I think I can agree with either of the two positions...
> >>
> >> I am guessing from the earlier iteration that you wanted to say
> >> "unless it is given explicitly, we turn it on".
> >>
> >> As this last-minute style update that was botched, and a typofix in
> >> the proposed log message in 8/8, are the only differences, let me
> >> locally fix 8/8 up and replace it.
> >
> > Sure. I still would like the `isset` thing, as it makes things more
> > consistent, but I'll not fight for it.
>
> ${var:+isset} is fine. Instead of
>
> +# Disallow the use of abbreviated options in the test suite by default
> +if test -z "${GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS}"
> +then
> + GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS=true
> + export GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS
> +fi
> +
>
> if you used
>
> if test -z "${GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS:+isset}"
> then
> ...
>
> I won't object. After all, I know I introduced :+isset pattern to
> our shell script codebase as there are cases where it makes the
> result easier to follow.
>
> But the thing is that your patch had the polarity inverted.Ah! I finally understand what you are saying. Took me a while, sorry.
> Where you must say "if this thing is not set, assign this value", you > said "if this thing is set, assign this value", which was totally bogus. > As long as that is corrected, that's fine.
Of course! It should be `-z` instead of `-n` there.
Show 17 quoted lines
> Having said that.
>
> When you check if the variable is set, use of the ":+isset" pattern
> makes the result often easier to follow by explicitly letting us
> compare with an explicit "isset" token, e.g.
>
> case ",${VAR1:+isset},${VAR2:+isset}," in
> *,isset,*) : at least one is set ;;
> *) : neither is set ;;
> esac
>
> This *does* make the code simpler and easier. But when checking for
> "is it not set?", you can compare with an explicit literal "" and
> that comparison is plenty clear enough. You won't get as much
> benefit as the "is it set?" test would out of the pattern. I would
> not say that it is pointless to use the ":+isset" pattern when
> checking "is it not set?", but it is very close.Well, there is also the subtelty that somebody might *want* to set that environment variable to the empty string (and obviously they would not deem it appropriate for us to override their choice).
But I do have bigger fish to fry, so if you're fine with the `isset` thing (fixed, of course), please go for it. If you'd prefer the version without it, that's fine enough with me, too.
Ciao, Dscho