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.schinde...@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
