Re: [PATCH 8/8] tests: disallow the use of abbreviated options (by default)

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Denton,

On Mon, 25 Mar 2019, Denton Liu wrote:

> Thanks for catching this. Perhaps I should've been more diligent and ran
> the entire test suite before submitting but I was running low on
> batteries only ran the rebase-related tests.

No worries.

> On Mon, Mar 25, 2019 at 11:14:23AM -0700, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > Git's command-line parsers support uniquely abbreviated options, e.g.
> > `git init --ba` would automatically expand `--ba` to `--bare`.
> >
> > This is a very convenient feature in every day life for Git users, in
> > particular when tab completion is not available.
> >
> > However, it is not a good idea to rely on that in Git's test suite, as
> > something that is a unique abbreviation of a command line option today
> > might no longer be a unique abbreviation tomorrow.
> >
> > For example, if a future contribution added a new mode
> > `git init --babyproofing` and a previously-introduced test case used the
> > fact that `git init --ba` expaneded to `git init --bare`, that future
>
> s/expaneded/expanded/

Thanks, fixed.

> > @@ -325,6 +329,7 @@ file: (not set)
> >  EOF
> >
> >  test_expect_success 'negation of OPT_NONEG flags is not ambiguous' '
> > +	GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS=false \
> >  	test-tool parse-options --no-ambig >output 2>output.err &&
> >  	test_must_be_empty output.err &&
> >  	test_cmp expect output
>
> Would it make sense to include a test case to ensure that
> GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS is working properly?

Yep, absolutely.

Thank you,
Dscho