Re: [PATCH 8/8] tests: disallow the use of abbreviated options (by default)
- Date: Fri, 12 Apr 2019 10:50:51 +0200 (DST)
- From: Johannes Schindelin <Johannes.Schindelin@xxxxxx>
- Subject: Re: [PATCH 8/8] tests: disallow the use of abbreviated options (by default)
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.
> On Mon, Mar 25, 2019 at 11:14:23AM -0700, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin <johannes.schindelin@xxxxxx>
> > 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
> > @@ -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?