2007-10-13 16:34:45 +00:00
|
|
|
#!/bin/sh
|
|
|
|
#
|
|
|
|
# Copyright (c) 2007 Johannes Schindelin
|
|
|
|
#
|
|
|
|
|
|
|
|
test_description='our own option parser'
|
|
|
|
|
2021-10-07 10:01:32 +00:00
|
|
|
TEST_PASSES_SANITIZE_LEAK=true
|
2007-10-13 16:34:45 +00:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
2016-04-12 23:02:17 +00:00
|
|
|
cat >expect <<\EOF
|
2018-09-09 17:36:29 +00:00
|
|
|
usage: test-tool parse-options <options>
|
2007-10-13 16:34:45 +00:00
|
|
|
|
2017-09-25 04:08:03 +00:00
|
|
|
A helper function for the parse-options API.
|
|
|
|
|
2023-08-05 14:40:59 +00:00
|
|
|
--[no-]yes get a boolean
|
2023-08-05 14:44:45 +00:00
|
|
|
-D, --no-doubt begins with 'no-'
|
|
|
|
--doubt opposite of --no-doubt
|
2012-02-25 19:11:16 +00:00
|
|
|
-B, --no-fear be brave
|
2023-08-05 14:40:59 +00:00
|
|
|
-b, --[no-]boolean increment by one
|
|
|
|
-4, --[no-]or4 bitwise-or boolean with ...0100
|
|
|
|
--[no-]neg-or4 same as --no-or4
|
2008-06-22 15:04:26 +00:00
|
|
|
|
2023-08-05 14:40:59 +00:00
|
|
|
-i, --[no-]integer <n>
|
|
|
|
get a integer
|
2007-10-13 16:34:45 +00:00
|
|
|
-j <n> get a integer, too
|
2015-06-21 18:25:44 +00:00
|
|
|
-m, --magnitude <n> get a magnitude
|
2023-08-05 14:40:59 +00:00
|
|
|
--[no-]set23 set integer to 23
|
2020-02-20 14:15:15 +00:00
|
|
|
--mode1 set integer to 1 (cmdmode option)
|
|
|
|
--mode2 set integer to 2 (cmdmode option)
|
parse-options: make CMDMODE errors more precise
Only a single PARSE_OPT_CMDMODE option can be specified for the same
variable at the same time. This is enforced by get_value(), but the
error messages are imprecise in three ways:
1. If a non-PARSE_OPT_CMDMODE option changes the value variable of a
PARSE_OPT_CMDMODE option then an ominously vague message is shown:
$ t/helper/test-tool parse-options --set23 --mode1
error: option `mode1' : incompatible with something else
Worse: If the order of options is reversed then no error is reported at
all:
$ t/helper/test-tool parse-options --mode1 --set23
boolean: 0
integer: 23
magnitude: 0
timestamp: 0
string: (not set)
abbrev: 7
verbose: -1
quiet: 0
dry run: no
file: (not set)
Fortunately this can currently only happen in the test helper; actual
Git commands don't share the same variable for the value of options with
and without the flag PARSE_OPT_CMDMODE.
2. If there are multiple options with the same value (synonyms), then
the one that is defined first is shown rather than the one actually
given on the command line, which is confusing:
$ git am --resolved --quit
error: option `quit' is incompatible with --continue
3. Arguments of PARSE_OPT_CMDMODE options are not handled by the
parse-option machinery. This is left to the callback function. We
currently only have a single affected option, --show-current-patch of
git am. Errors for it can show an argument that was not actually given
on the command line:
$ git am --show-current-patch --show-current-patch=diff
error: options '--show-current-patch=diff' and '--show-current-patch=raw' cannot be used together
The options --show-current-patch and --show-current-patch=raw are
synonyms, but the error accuses the user of input they did not actually
made. Or it can awkwardly print a NULL pointer:
$ git am --show-current-patch=diff --show-current-patch
error: options '--show-current-patch=(null)' and '--show-current-patch=diff' cannot be used together
The reasons for these shortcomings is that the current code checks
incompatibility only when encountering a PARSE_OPT_CMDMODE option at the
command line, and that it searches the previous incompatible option by
value.
Fix the first two points by checking all PARSE_OPT_CMDMODE variables
after parsing each option and by storing all relevant details if their
value changed. Do that whether or not the changing options has the flag
PARSE_OPT_CMDMODE set. Report an incompatibility only if two options
change the variable to different values and at least one of them is a
PARSE_OPT_CMDMODE option. This changes the output of the first three
examples above to:
$ t/helper/test-tool parse-options --set23 --mode1
error: --mode1 is incompatible with --set23
$ t/helper/test-tool parse-options --mode1 --set23
error: --set23 is incompatible with --mode1
$ git am --resolved --quit
error: --quit is incompatible with --resolved
Store the argument of PARSE_OPT_CMDMODE options of type OPTION_CALLBACK
as well to allow taking over the responsibility for compatibility
checking from the callback function. The next patch will use this
capability to fix the messages for git am --show-current-patch.
Use a linked list for storing the PARSE_OPT_CMDMODE variables. This
somewhat outdated data structure is simple and suffices, as the number
of elements per command is currently only zero or one. We do support
multiple different command modes variables per command, but I don't
expect that we'd ever use a significant number of them. Once we do we
can switch to a hashmap.
Since we no longer need to search the conflicting option, the all_opts
parameter of get_value() is no longer used. Remove it.
Extend the tests to check for both conflicting option names, but don't
insist on a particular order.
Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-10-28 11:53:01 +00:00
|
|
|
--[no-]mode34 (3|4) set integer to 3 or 4 (cmdmode option)
|
2023-08-05 14:40:59 +00:00
|
|
|
-L, --[no-]length <str>
|
|
|
|
get length of <str>
|
|
|
|
-F, --[no-]file <file>
|
|
|
|
set file to <file>
|
2007-10-13 16:34:45 +00:00
|
|
|
|
2008-06-22 15:04:26 +00:00
|
|
|
String options
|
2023-08-05 14:40:59 +00:00
|
|
|
-s, --[no-]string <string>
|
|
|
|
get a string
|
|
|
|
--[no-]string2 <str> get another string
|
|
|
|
--[no-]st <st> get another string (pervert ordering)
|
2008-01-26 11:26:57 +00:00
|
|
|
-o <str> get another string
|
2023-07-18 22:54:04 +00:00
|
|
|
--longhelp help text of this entry
|
|
|
|
spans multiple lines
|
2023-08-05 14:40:59 +00:00
|
|
|
--[no-]list <str> add str to list
|
2007-10-13 16:34:45 +00:00
|
|
|
|
2008-06-22 15:04:26 +00:00
|
|
|
Magic arguments
|
2009-05-07 19:45:08 +00:00
|
|
|
-NUM set integer to NUM
|
2009-05-07 19:45:42 +00:00
|
|
|
+ same as -b
|
2009-09-25 18:44:44 +00:00
|
|
|
--ambiguous positive ambiguity
|
|
|
|
--no-ambiguous negative ambiguity
|
2008-03-02 10:35:56 +00:00
|
|
|
|
2008-06-22 15:04:26 +00:00
|
|
|
Standard options
|
2023-08-05 14:40:59 +00:00
|
|
|
--[no-]abbrev[=<n>] use <n> digits to display object names
|
|
|
|
-v, --[no-]verbose be verbose
|
|
|
|
-n, --[no-]dry-run dry run
|
|
|
|
-q, --[no-]quiet be quiet
|
|
|
|
--[no-]expect <string>
|
|
|
|
expected output in the variable dump
|
2008-06-22 15:04:26 +00:00
|
|
|
|
2019-04-29 10:05:25 +00:00
|
|
|
Alias
|
2023-08-05 14:40:59 +00:00
|
|
|
-A, --[no-]alias-source <string>
|
2019-04-29 10:05:25 +00:00
|
|
|
get a string
|
2023-08-05 14:40:59 +00:00
|
|
|
-Z, --[no-]alias-target <string>
|
2020-03-16 20:22:54 +00:00
|
|
|
alias of --alias-source
|
2019-04-29 10:05:25 +00:00
|
|
|
|
2007-10-13 16:34:45 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_success 'test help' '
|
2018-09-09 17:36:29 +00:00
|
|
|
test_must_fail test-tool parse-options -h >output 2>output.err &&
|
2013-06-09 18:29:20 +00:00
|
|
|
test_must_be_empty output.err &&
|
2021-02-11 01:53:53 +00:00
|
|
|
test_cmp expect output
|
2007-10-13 16:34:45 +00:00
|
|
|
'
|
|
|
|
|
2010-05-17 15:34:41 +00:00
|
|
|
mv expect expect.err
|
|
|
|
|
2016-05-06 18:17:05 +00:00
|
|
|
check () {
|
2012-02-25 19:11:16 +00:00
|
|
|
what="$1" &&
|
|
|
|
shift &&
|
|
|
|
expect="$1" &&
|
|
|
|
shift &&
|
2018-09-09 17:36:29 +00:00
|
|
|
test-tool parse-options --expect="$what $expect" "$@"
|
2012-02-25 19:11:16 +00:00
|
|
|
}
|
|
|
|
|
2012-08-27 05:36:55 +00:00
|
|
|
check_unknown_i18n() {
|
|
|
|
case "$1" in
|
|
|
|
--*)
|
|
|
|
echo error: unknown option \`${1#--}\' >expect ;;
|
|
|
|
-*)
|
|
|
|
echo error: unknown switch \`${1#-}\' >expect ;;
|
|
|
|
esac &&
|
|
|
|
cat expect.err >>expect &&
|
2018-09-09 17:36:29 +00:00
|
|
|
test_must_fail test-tool parse-options $* >output 2>output.err &&
|
2013-06-09 18:29:20 +00:00
|
|
|
test_must_be_empty output &&
|
2021-02-11 01:53:53 +00:00
|
|
|
test_cmp expect output.err
|
2012-08-27 05:36:55 +00:00
|
|
|
}
|
|
|
|
|
2012-02-25 19:11:16 +00:00
|
|
|
test_expect_success 'OPT_BOOL() #1' 'check boolean: 1 --yes'
|
|
|
|
test_expect_success 'OPT_BOOL() #2' 'check boolean: 1 --no-doubt'
|
|
|
|
test_expect_success 'OPT_BOOL() #3' 'check boolean: 1 -D'
|
|
|
|
test_expect_success 'OPT_BOOL() #4' 'check boolean: 1 --no-fear'
|
|
|
|
test_expect_success 'OPT_BOOL() #5' 'check boolean: 1 -B'
|
|
|
|
|
|
|
|
test_expect_success 'OPT_BOOL() is idempotent #1' 'check boolean: 1 --yes --yes'
|
|
|
|
test_expect_success 'OPT_BOOL() is idempotent #2' 'check boolean: 1 -DB'
|
|
|
|
|
|
|
|
test_expect_success 'OPT_BOOL() negation #1' 'check boolean: 0 -D --no-yes'
|
|
|
|
test_expect_success 'OPT_BOOL() negation #2' 'check boolean: 0 -D --no-no-doubt'
|
|
|
|
|
2017-09-25 04:08:04 +00:00
|
|
|
test_expect_success 'OPT_BOOL() no negation #1' 'check_unknown_i18n --fear'
|
|
|
|
test_expect_success 'OPT_BOOL() no negation #2' 'check_unknown_i18n --no-no-fear'
|
2012-02-25 19:11:16 +00:00
|
|
|
|
2012-02-25 19:14:54 +00:00
|
|
|
test_expect_success 'OPT_BOOL() positivation' 'check boolean: 0 -D --doubt'
|
2012-02-25 19:11:16 +00:00
|
|
|
|
2015-06-21 18:25:43 +00:00
|
|
|
test_expect_success 'OPT_INT() negative' 'check integer: -2345 -i -2345'
|
|
|
|
|
2015-06-21 18:25:44 +00:00
|
|
|
test_expect_success 'OPT_MAGNITUDE() simple' '
|
|
|
|
check magnitude: 2345678 -m 2345678
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'OPT_MAGNITUDE() kilo' '
|
|
|
|
check magnitude: 239616 -m 234k
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'OPT_MAGNITUDE() mega' '
|
|
|
|
check magnitude: 104857600 -m 100m
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'OPT_MAGNITUDE() giga' '
|
|
|
|
check magnitude: 1073741824 -m 1g
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'OPT_MAGNITUDE() 3giga' '
|
|
|
|
check magnitude: 3221225472 -m 3g
|
|
|
|
'
|
|
|
|
|
2016-04-12 23:02:17 +00:00
|
|
|
cat >expect <<\EOF
|
2007-10-13 16:34:45 +00:00
|
|
|
boolean: 2
|
|
|
|
integer: 1729
|
2015-06-21 18:25:44 +00:00
|
|
|
magnitude: 16384
|
2008-07-30 19:53:45 +00:00
|
|
|
timestamp: 0
|
2007-10-13 16:34:45 +00:00
|
|
|
string: 123
|
2008-06-22 15:04:26 +00:00
|
|
|
abbrev: 7
|
|
|
|
verbose: 2
|
2016-04-12 23:02:17 +00:00
|
|
|
quiet: 0
|
2008-06-22 15:04:26 +00:00
|
|
|
dry run: yes
|
2009-05-23 18:53:13 +00:00
|
|
|
file: prefix/my.file
|
2007-10-13 16:34:45 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_success 'short options' '
|
2018-09-09 17:36:29 +00:00
|
|
|
test-tool parse-options -s123 -b -i 1729 -m 16k -b -vv -n -F my.file \
|
2015-06-21 18:25:44 +00:00
|
|
|
>output 2>output.err &&
|
2008-05-24 05:28:56 +00:00
|
|
|
test_cmp expect output &&
|
2013-06-09 18:29:20 +00:00
|
|
|
test_must_be_empty output.err
|
2007-10-13 16:34:45 +00:00
|
|
|
'
|
2008-06-22 15:04:26 +00:00
|
|
|
|
2016-04-12 23:02:17 +00:00
|
|
|
cat >expect <<\EOF
|
2007-10-13 16:34:45 +00:00
|
|
|
boolean: 2
|
|
|
|
integer: 1729
|
2015-06-21 18:25:44 +00:00
|
|
|
magnitude: 16384
|
2008-07-30 19:53:45 +00:00
|
|
|
timestamp: 0
|
2007-10-13 16:34:45 +00:00
|
|
|
string: 321
|
2008-06-22 15:04:26 +00:00
|
|
|
abbrev: 10
|
|
|
|
verbose: 2
|
2016-04-12 23:02:17 +00:00
|
|
|
quiet: 0
|
2008-06-22 15:04:26 +00:00
|
|
|
dry run: no
|
2009-05-23 18:53:13 +00:00
|
|
|
file: prefix/fi.le
|
2007-10-13 16:34:45 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_success 'long options' '
|
2018-09-09 17:36:29 +00:00
|
|
|
test-tool parse-options --boolean --integer 1729 --magnitude 16k \
|
2015-06-21 18:25:44 +00:00
|
|
|
--boolean --string2=321 --verbose --verbose --no-dry-run \
|
|
|
|
--abbrev=10 --file fi.le --obsolete \
|
|
|
|
>output 2>output.err &&
|
2013-06-09 18:29:20 +00:00
|
|
|
test_must_be_empty output.err &&
|
2008-05-24 05:28:56 +00:00
|
|
|
test_cmp expect output
|
2007-10-13 16:34:45 +00:00
|
|
|
'
|
|
|
|
|
2024-05-07 04:52:56 +00:00
|
|
|
test_expect_success 'abbreviate to something longer than SHA1 length' '
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
boolean: 0
|
|
|
|
integer: 0
|
|
|
|
magnitude: 0
|
|
|
|
timestamp: 0
|
|
|
|
string: (not set)
|
|
|
|
abbrev: 100
|
|
|
|
verbose: -1
|
|
|
|
quiet: 0
|
|
|
|
dry run: no
|
|
|
|
file: (not set)
|
|
|
|
EOF
|
|
|
|
test-tool parse-options --abbrev=100 >output &&
|
|
|
|
test_cmp expect output
|
|
|
|
'
|
|
|
|
|
2008-07-21 18:30:36 +00:00
|
|
|
test_expect_success 'missing required value' '
|
2021-10-08 19:07:45 +00:00
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
error: switch `s'\'' requires a value
|
|
|
|
EOF
|
|
|
|
test_expect_code 129 test-tool parse-options -s 2>actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
error: option `string'\'' requires a value
|
|
|
|
EOF
|
|
|
|
test_expect_code 129 test-tool parse-options --string 2>actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
error: option `file'\'' requires a value
|
|
|
|
EOF
|
|
|
|
test_expect_code 129 test-tool parse-options --file 2>actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'superfluous value provided: boolean' '
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
error: option `yes'\'' takes no value
|
|
|
|
EOF
|
|
|
|
test_expect_code 129 test-tool parse-options --yes=hi 2>actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
error: option `no-yes'\'' takes no value
|
|
|
|
EOF
|
|
|
|
test_expect_code 129 test-tool parse-options --no-yes=hi 2>actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2024-03-03 12:19:38 +00:00
|
|
|
test_expect_success 'superfluous value provided: boolean, abbreviated' '
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
error: option `yes'\'' takes no value
|
|
|
|
EOF
|
|
|
|
test_expect_code 129 env GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS=false \
|
|
|
|
test-tool parse-options --ye=hi 2>actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
error: option `no-yes'\'' takes no value
|
|
|
|
EOF
|
|
|
|
test_expect_code 129 env GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS=false \
|
|
|
|
test-tool parse-options --no-ye=hi 2>actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2021-10-08 19:07:45 +00:00
|
|
|
test_expect_success 'superfluous value provided: cmdmode' '
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
error: option `mode1'\'' takes no value
|
|
|
|
EOF
|
|
|
|
test_expect_code 129 test-tool parse-options --mode1=hi 2>actual &&
|
|
|
|
test_cmp expect actual
|
2008-07-21 18:30:36 +00:00
|
|
|
'
|
|
|
|
|
2016-04-12 23:02:17 +00:00
|
|
|
cat >expect <<\EOF
|
2007-10-13 16:34:45 +00:00
|
|
|
boolean: 1
|
|
|
|
integer: 13
|
2015-06-21 18:25:44 +00:00
|
|
|
magnitude: 0
|
2008-07-30 19:53:45 +00:00
|
|
|
timestamp: 0
|
2007-10-13 16:34:45 +00:00
|
|
|
string: 123
|
2008-06-22 15:04:26 +00:00
|
|
|
abbrev: 7
|
parse-options.c: make OPTION_COUNTUP respect "unspecified" values
OPT_COUNTUP() merely increments the counter upon --option, and resets it
to 0 upon --no-option, which means that there is no "unspecified" value
with which a client can initialize the counter to determine whether or
not --[no]-option was seen at all.
Make OPT_COUNTUP() treat any negative number as an "unspecified" value
to address this shortcoming. In particular, if a client initializes the
counter to -1, then if it is still -1 after parse_options(), then
neither --option nor --no-option was seen; if it is 0, then --no-option
was seen last, and if it is 1 or greater, than --option was seen last.
This change does not affect the behavior of existing clients because
they all use the initial value of 0 (or more).
Note that builtin/clean.c initializes the variable used with
OPT__FORCE (which uses OPT_COUNTUP()) to a negative value, but it is set
to either 0 or 1 by reading the configuration before the code calls
parse_options(), i.e. as far as parse_options() is concerned, the
initial value of the variable is not negative.
To test this behavior, in test-parse-options.c, "verbose" is set to
"unspecified" while quiet is set to 0 which will test the new behavior
with all sets of values.
Helped-by: Jeff King <peff@peff.net>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-05 09:50:00 +00:00
|
|
|
verbose: -1
|
2016-04-12 23:02:17 +00:00
|
|
|
quiet: 0
|
2008-06-22 15:04:26 +00:00
|
|
|
dry run: no
|
2009-05-23 18:53:13 +00:00
|
|
|
file: (not set)
|
2007-10-13 16:34:45 +00:00
|
|
|
arg 00: a1
|
|
|
|
arg 01: b1
|
|
|
|
arg 02: --boolean
|
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_success 'intermingled arguments' '
|
2018-09-09 17:36:29 +00:00
|
|
|
test-tool parse-options a1 --string 123 b1 --boolean -j 13 -- --boolean \
|
2016-04-12 23:02:17 +00:00
|
|
|
>output 2>output.err &&
|
2013-06-09 18:29:20 +00:00
|
|
|
test_must_be_empty output.err &&
|
2008-05-24 05:28:56 +00:00
|
|
|
test_cmp expect output
|
2007-10-13 16:34:45 +00:00
|
|
|
'
|
|
|
|
|
2016-04-12 23:02:17 +00:00
|
|
|
cat >expect <<\EOF
|
2007-10-14 16:54:06 +00:00
|
|
|
boolean: 0
|
|
|
|
integer: 2
|
2015-06-21 18:25:44 +00:00
|
|
|
magnitude: 0
|
2008-07-30 19:53:45 +00:00
|
|
|
timestamp: 0
|
2007-10-14 16:54:06 +00:00
|
|
|
string: (not set)
|
2008-06-22 15:04:26 +00:00
|
|
|
abbrev: 7
|
parse-options.c: make OPTION_COUNTUP respect "unspecified" values
OPT_COUNTUP() merely increments the counter upon --option, and resets it
to 0 upon --no-option, which means that there is no "unspecified" value
with which a client can initialize the counter to determine whether or
not --[no]-option was seen at all.
Make OPT_COUNTUP() treat any negative number as an "unspecified" value
to address this shortcoming. In particular, if a client initializes the
counter to -1, then if it is still -1 after parse_options(), then
neither --option nor --no-option was seen; if it is 0, then --no-option
was seen last, and if it is 1 or greater, than --option was seen last.
This change does not affect the behavior of existing clients because
they all use the initial value of 0 (or more).
Note that builtin/clean.c initializes the variable used with
OPT__FORCE (which uses OPT_COUNTUP()) to a negative value, but it is set
to either 0 or 1 by reading the configuration before the code calls
parse_options(), i.e. as far as parse_options() is concerned, the
initial value of the variable is not negative.
To test this behavior, in test-parse-options.c, "verbose" is set to
"unspecified" while quiet is set to 0 which will test the new behavior
with all sets of values.
Helped-by: Jeff King <peff@peff.net>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-05 09:50:00 +00:00
|
|
|
verbose: -1
|
2016-04-12 23:02:17 +00:00
|
|
|
quiet: 0
|
2008-06-22 15:04:26 +00:00
|
|
|
dry run: no
|
2009-05-23 18:53:13 +00:00
|
|
|
file: (not set)
|
2007-10-14 16:54:06 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_success 'unambiguously abbreviated option' '
|
tests: disallow the use of abbreviated options (by default)
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` expanded to `git init --bare`, that future
contribution would now have to touch seemingly unrelated tests just to
keep the test suite from failing.
So let's disallow abbreviated options in the test suite by default.
Note: for ease of implementation, this patch really only touches the
`parse-options` machinery: more and more hand-rolled option parsers are
converted to use that internal API, and more and more scripts are
converted to built-ins (naturally using the parse-options API, too), so
in practice this catches most issues, and is definitely the biggest bang
for the buck.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-12 09:37:24 +00:00
|
|
|
GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS=false \
|
2018-09-09 17:36:29 +00:00
|
|
|
test-tool parse-options --int 2 --boolean --no-bo >output 2>output.err &&
|
2013-06-09 18:29:20 +00:00
|
|
|
test_must_be_empty output.err &&
|
2008-05-24 05:28:56 +00:00
|
|
|
test_cmp expect output
|
2007-10-14 16:54:06 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'unambiguously abbreviated option with "="' '
|
tests: disallow the use of abbreviated options (by default)
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` expanded to `git init --bare`, that future
contribution would now have to touch seemingly unrelated tests just to
keep the test suite from failing.
So let's disallow abbreviated options in the test suite by default.
Note: for ease of implementation, this patch really only touches the
`parse-options` machinery: more and more hand-rolled option parsers are
converted to use that internal API, and more and more scripts are
converted to built-ins (naturally using the parse-options API, too), so
in practice this catches most issues, and is definitely the biggest bang
for the buck.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-12 09:37:24 +00:00
|
|
|
GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS=false \
|
2018-09-09 17:36:29 +00:00
|
|
|
test-tool parse-options --expect="integer: 2" --int=2
|
2007-10-14 16:54:06 +00:00
|
|
|
'
|
|
|
|
|
2008-02-01 09:50:53 +00:00
|
|
|
test_expect_success 'ambiguously abbreviated option' '
|
tests: disallow the use of abbreviated options (by default)
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` expanded to `git init --bare`, that future
contribution would now have to touch seemingly unrelated tests just to
keep the test suite from failing.
So let's disallow abbreviated options in the test suite by default.
Note: for ease of implementation, this patch really only touches the
`parse-options` machinery: more and more hand-rolled option parsers are
converted to use that internal API, and more and more scripts are
converted to built-ins (naturally using the parse-options API, too), so
in practice this catches most issues, and is definitely the biggest bang
for the buck.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-12 09:37:24 +00:00
|
|
|
test_expect_code 129 env GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS=false \
|
|
|
|
test-tool parse-options --strin 123
|
2007-10-14 16:54:06 +00:00
|
|
|
'
|
|
|
|
|
2007-11-05 13:15:21 +00:00
|
|
|
test_expect_success 'non ambiguous option (after two options it abbreviates)' '
|
tests: disallow the use of abbreviated options (by default)
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` expanded to `git init --bare`, that future
contribution would now have to touch seemingly unrelated tests just to
keep the test suite from failing.
So let's disallow abbreviated options in the test suite by default.
Note: for ease of implementation, this patch really only touches the
`parse-options` machinery: more and more hand-rolled option parsers are
converted to use that internal API, and more and more scripts are
converted to built-ins (naturally using the parse-options API, too), so
in practice this catches most issues, and is definitely the biggest bang
for the buck.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-12 09:37:24 +00:00
|
|
|
GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS=false \
|
2018-09-09 17:36:29 +00:00
|
|
|
test-tool parse-options --expect="string: 123" --st 123
|
2007-11-05 13:15:21 +00:00
|
|
|
'
|
|
|
|
|
2019-04-29 10:05:25 +00:00
|
|
|
test_expect_success 'Alias options do not contribute to abbreviation' '
|
|
|
|
test-tool parse-options --alias-source 123 >output &&
|
|
|
|
grep "^string: 123" output &&
|
|
|
|
test-tool parse-options --alias-target 123 >output &&
|
|
|
|
grep "^string: 123" output &&
|
|
|
|
test_must_fail test-tool parse-options --alias &&
|
|
|
|
GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS=false \
|
|
|
|
test-tool parse-options --alias 123 >output &&
|
|
|
|
grep "^string: 123" output
|
|
|
|
'
|
|
|
|
|
2016-04-12 23:02:17 +00:00
|
|
|
cat >typo.err <<\EOF
|
2020-02-05 13:07:23 +00:00
|
|
|
error: did you mean `--boolean` (with two dashes)?
|
2008-01-26 11:26:57 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_success 'detect possible typos' '
|
2018-09-09 17:36:29 +00:00
|
|
|
test_must_fail test-tool parse-options -boolean >output 2>output.err &&
|
2013-06-09 18:29:20 +00:00
|
|
|
test_must_be_empty output &&
|
2021-02-11 01:53:53 +00:00
|
|
|
test_cmp typo.err output.err
|
2008-01-26 11:26:57 +00:00
|
|
|
'
|
|
|
|
|
2016-04-12 23:02:17 +00:00
|
|
|
cat >typo.err <<\EOF
|
2020-02-05 13:07:23 +00:00
|
|
|
error: did you mean `--ambiguous` (with two dashes)?
|
2012-03-03 11:00:29 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_success 'detect possible typos' '
|
2018-09-09 17:36:29 +00:00
|
|
|
test_must_fail test-tool parse-options -ambiguous >output 2>output.err &&
|
2013-06-09 18:29:20 +00:00
|
|
|
test_must_be_empty output &&
|
2021-02-11 01:53:53 +00:00
|
|
|
test_cmp typo.err output.err
|
2012-03-03 11:00:29 +00:00
|
|
|
'
|
|
|
|
|
2016-04-12 23:02:17 +00:00
|
|
|
cat >expect <<\EOF
|
2008-06-22 15:04:26 +00:00
|
|
|
Callback: "four", 0
|
|
|
|
boolean: 5
|
|
|
|
integer: 4
|
2015-06-21 18:25:44 +00:00
|
|
|
magnitude: 0
|
2008-07-30 19:53:45 +00:00
|
|
|
timestamp: 0
|
2008-06-22 15:04:26 +00:00
|
|
|
string: (not set)
|
|
|
|
abbrev: 7
|
parse-options.c: make OPTION_COUNTUP respect "unspecified" values
OPT_COUNTUP() merely increments the counter upon --option, and resets it
to 0 upon --no-option, which means that there is no "unspecified" value
with which a client can initialize the counter to determine whether or
not --[no]-option was seen at all.
Make OPT_COUNTUP() treat any negative number as an "unspecified" value
to address this shortcoming. In particular, if a client initializes the
counter to -1, then if it is still -1 after parse_options(), then
neither --option nor --no-option was seen; if it is 0, then --no-option
was seen last, and if it is 1 or greater, than --option was seen last.
This change does not affect the behavior of existing clients because
they all use the initial value of 0 (or more).
Note that builtin/clean.c initializes the variable used with
OPT__FORCE (which uses OPT_COUNTUP()) to a negative value, but it is set
to either 0 or 1 by reading the configuration before the code calls
parse_options(), i.e. as far as parse_options() is concerned, the
initial value of the variable is not negative.
To test this behavior, in test-parse-options.c, "verbose" is set to
"unspecified" while quiet is set to 0 which will test the new behavior
with all sets of values.
Helped-by: Jeff King <peff@peff.net>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-05 09:50:00 +00:00
|
|
|
verbose: -1
|
2016-04-12 23:02:17 +00:00
|
|
|
quiet: 0
|
2008-06-22 15:04:26 +00:00
|
|
|
dry run: no
|
2009-05-23 18:53:13 +00:00
|
|
|
file: (not set)
|
2008-06-22 15:04:26 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_success 'OPT_CALLBACK() and OPT_BIT() work' '
|
2018-09-09 17:36:29 +00:00
|
|
|
test-tool parse-options --length=four -b -4 >output 2>output.err &&
|
2013-06-09 18:29:20 +00:00
|
|
|
test_must_be_empty output.err &&
|
2008-06-22 15:04:26 +00:00
|
|
|
test_cmp expect output
|
|
|
|
'
|
|
|
|
|
2017-09-25 04:08:04 +00:00
|
|
|
test_expect_success 'OPT_CALLBACK() and callback errors work' '
|
2018-09-09 17:36:29 +00:00
|
|
|
test_must_fail test-tool parse-options --no-length >output 2>output.err &&
|
tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>'
Using 'test_must_be_empty' is shorter and more idiomatic than
>empty &&
test_cmp empty out
as it saves the creation of an empty file. Furthermore, sometimes the
expected empty file doesn't have such a descriptive name like 'empty',
and its creation is far away from the place where it's finally used
for comparison (e.g. in 't7600-merge.sh', where two expected empty
files are created in the 'setup' test, but are used only about 500
lines later).
These cases were found by instrumenting 'test_cmp' to error out the
test script when it's used to compare empty files, and then converted
manually.
Note that even after this patch there still remain a lot of cases
where we use 'test_cmp' to check empty files:
- Sometimes the expected output is not hard-coded in the test, but
'test_cmp' is used to ensure that two similar git commands produce
the same output, and that output happens to be empty, e.g. the
test 'submodule update --merge - ignores --merge for new
submodules' in 't7406-submodule-update.sh'.
- Repetitive common tasks, including preparing the expected results
and running 'test_cmp', are often extracted into a helper
function, and some of this helper's callsites expect no output.
- For the same reason as above, the whole 'test_expect_success'
block is within a helper function, e.g. in 't3070-wildmatch.sh'.
- Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update
(-p)' in 't9400-git-cvsserver-server.sh'.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-19 21:57:25 +00:00
|
|
|
test_must_be_empty output &&
|
2018-03-22 18:43:51 +00:00
|
|
|
test_must_be_empty output.err
|
2008-06-22 15:04:26 +00:00
|
|
|
'
|
|
|
|
|
2016-04-12 23:02:17 +00:00
|
|
|
cat >expect <<\EOF
|
2008-06-22 15:04:26 +00:00
|
|
|
boolean: 1
|
|
|
|
integer: 23
|
2015-06-21 18:25:44 +00:00
|
|
|
magnitude: 0
|
2008-07-30 19:53:45 +00:00
|
|
|
timestamp: 0
|
2008-06-22 15:04:26 +00:00
|
|
|
string: (not set)
|
|
|
|
abbrev: 7
|
parse-options.c: make OPTION_COUNTUP respect "unspecified" values
OPT_COUNTUP() merely increments the counter upon --option, and resets it
to 0 upon --no-option, which means that there is no "unspecified" value
with which a client can initialize the counter to determine whether or
not --[no]-option was seen at all.
Make OPT_COUNTUP() treat any negative number as an "unspecified" value
to address this shortcoming. In particular, if a client initializes the
counter to -1, then if it is still -1 after parse_options(), then
neither --option nor --no-option was seen; if it is 0, then --no-option
was seen last, and if it is 1 or greater, than --option was seen last.
This change does not affect the behavior of existing clients because
they all use the initial value of 0 (or more).
Note that builtin/clean.c initializes the variable used with
OPT__FORCE (which uses OPT_COUNTUP()) to a negative value, but it is set
to either 0 or 1 by reading the configuration before the code calls
parse_options(), i.e. as far as parse_options() is concerned, the
initial value of the variable is not negative.
To test this behavior, in test-parse-options.c, "verbose" is set to
"unspecified" while quiet is set to 0 which will test the new behavior
with all sets of values.
Helped-by: Jeff King <peff@peff.net>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-05 09:50:00 +00:00
|
|
|
verbose: -1
|
2016-04-12 23:02:17 +00:00
|
|
|
quiet: 0
|
2008-06-22 15:04:26 +00:00
|
|
|
dry run: no
|
2009-05-23 18:53:13 +00:00
|
|
|
file: (not set)
|
2008-06-22 15:04:26 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_success 'OPT_BIT() and OPT_SET_INT() work' '
|
2018-09-09 17:36:29 +00:00
|
|
|
test-tool parse-options --set23 -bbbbb --no-or4 >output 2>output.err &&
|
2013-06-09 18:29:20 +00:00
|
|
|
test_must_be_empty output.err &&
|
2008-06-22 15:04:26 +00:00
|
|
|
test_cmp expect output
|
|
|
|
'
|
|
|
|
|
2009-05-07 19:44:17 +00:00
|
|
|
test_expect_success 'OPT_NEGBIT() and OPT_SET_INT() work' '
|
2018-09-09 17:36:29 +00:00
|
|
|
test-tool parse-options --set23 -bbbbb --neg-or4 >output 2>output.err &&
|
2013-06-09 18:29:20 +00:00
|
|
|
test_must_be_empty output.err &&
|
2009-05-07 19:44:17 +00:00
|
|
|
test_cmp expect output
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'OPT_BIT() works' '
|
2018-09-09 17:36:29 +00:00
|
|
|
test-tool parse-options --expect="boolean: 6" -bb --or4
|
2009-05-07 19:44:17 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'OPT_NEGBIT() works' '
|
2018-09-09 17:36:29 +00:00
|
|
|
test-tool parse-options --expect="boolean: 6" -bb --no-neg-or4
|
2009-05-07 19:44:17 +00:00
|
|
|
'
|
2008-06-22 15:04:26 +00:00
|
|
|
|
2020-02-20 14:15:15 +00:00
|
|
|
test_expect_success 'OPT_CMDMODE() works' '
|
parse-options: make CMDMODE errors more precise
Only a single PARSE_OPT_CMDMODE option can be specified for the same
variable at the same time. This is enforced by get_value(), but the
error messages are imprecise in three ways:
1. If a non-PARSE_OPT_CMDMODE option changes the value variable of a
PARSE_OPT_CMDMODE option then an ominously vague message is shown:
$ t/helper/test-tool parse-options --set23 --mode1
error: option `mode1' : incompatible with something else
Worse: If the order of options is reversed then no error is reported at
all:
$ t/helper/test-tool parse-options --mode1 --set23
boolean: 0
integer: 23
magnitude: 0
timestamp: 0
string: (not set)
abbrev: 7
verbose: -1
quiet: 0
dry run: no
file: (not set)
Fortunately this can currently only happen in the test helper; actual
Git commands don't share the same variable for the value of options with
and without the flag PARSE_OPT_CMDMODE.
2. If there are multiple options with the same value (synonyms), then
the one that is defined first is shown rather than the one actually
given on the command line, which is confusing:
$ git am --resolved --quit
error: option `quit' is incompatible with --continue
3. Arguments of PARSE_OPT_CMDMODE options are not handled by the
parse-option machinery. This is left to the callback function. We
currently only have a single affected option, --show-current-patch of
git am. Errors for it can show an argument that was not actually given
on the command line:
$ git am --show-current-patch --show-current-patch=diff
error: options '--show-current-patch=diff' and '--show-current-patch=raw' cannot be used together
The options --show-current-patch and --show-current-patch=raw are
synonyms, but the error accuses the user of input they did not actually
made. Or it can awkwardly print a NULL pointer:
$ git am --show-current-patch=diff --show-current-patch
error: options '--show-current-patch=(null)' and '--show-current-patch=diff' cannot be used together
The reasons for these shortcomings is that the current code checks
incompatibility only when encountering a PARSE_OPT_CMDMODE option at the
command line, and that it searches the previous incompatible option by
value.
Fix the first two points by checking all PARSE_OPT_CMDMODE variables
after parsing each option and by storing all relevant details if their
value changed. Do that whether or not the changing options has the flag
PARSE_OPT_CMDMODE set. Report an incompatibility only if two options
change the variable to different values and at least one of them is a
PARSE_OPT_CMDMODE option. This changes the output of the first three
examples above to:
$ t/helper/test-tool parse-options --set23 --mode1
error: --mode1 is incompatible with --set23
$ t/helper/test-tool parse-options --mode1 --set23
error: --set23 is incompatible with --mode1
$ git am --resolved --quit
error: --quit is incompatible with --resolved
Store the argument of PARSE_OPT_CMDMODE options of type OPTION_CALLBACK
as well to allow taking over the responsibility for compatibility
checking from the callback function. The next patch will use this
capability to fix the messages for git am --show-current-patch.
Use a linked list for storing the PARSE_OPT_CMDMODE variables. This
somewhat outdated data structure is simple and suffices, as the number
of elements per command is currently only zero or one. We do support
multiple different command modes variables per command, but I don't
expect that we'd ever use a significant number of them. Once we do we
can switch to a hashmap.
Since we no longer need to search the conflicting option, the all_opts
parameter of get_value() is no longer used. Remove it.
Extend the tests to check for both conflicting option names, but don't
insist on a particular order.
Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-10-28 11:53:01 +00:00
|
|
|
test-tool parse-options --expect="integer: 1" --mode1 &&
|
|
|
|
test-tool parse-options --expect="integer: 3" --mode34=3
|
2020-02-20 14:15:15 +00:00
|
|
|
'
|
|
|
|
|
parse-options: make CMDMODE errors more precise
Only a single PARSE_OPT_CMDMODE option can be specified for the same
variable at the same time. This is enforced by get_value(), but the
error messages are imprecise in three ways:
1. If a non-PARSE_OPT_CMDMODE option changes the value variable of a
PARSE_OPT_CMDMODE option then an ominously vague message is shown:
$ t/helper/test-tool parse-options --set23 --mode1
error: option `mode1' : incompatible with something else
Worse: If the order of options is reversed then no error is reported at
all:
$ t/helper/test-tool parse-options --mode1 --set23
boolean: 0
integer: 23
magnitude: 0
timestamp: 0
string: (not set)
abbrev: 7
verbose: -1
quiet: 0
dry run: no
file: (not set)
Fortunately this can currently only happen in the test helper; actual
Git commands don't share the same variable for the value of options with
and without the flag PARSE_OPT_CMDMODE.
2. If there are multiple options with the same value (synonyms), then
the one that is defined first is shown rather than the one actually
given on the command line, which is confusing:
$ git am --resolved --quit
error: option `quit' is incompatible with --continue
3. Arguments of PARSE_OPT_CMDMODE options are not handled by the
parse-option machinery. This is left to the callback function. We
currently only have a single affected option, --show-current-patch of
git am. Errors for it can show an argument that was not actually given
on the command line:
$ git am --show-current-patch --show-current-patch=diff
error: options '--show-current-patch=diff' and '--show-current-patch=raw' cannot be used together
The options --show-current-patch and --show-current-patch=raw are
synonyms, but the error accuses the user of input they did not actually
made. Or it can awkwardly print a NULL pointer:
$ git am --show-current-patch=diff --show-current-patch
error: options '--show-current-patch=(null)' and '--show-current-patch=diff' cannot be used together
The reasons for these shortcomings is that the current code checks
incompatibility only when encountering a PARSE_OPT_CMDMODE option at the
command line, and that it searches the previous incompatible option by
value.
Fix the first two points by checking all PARSE_OPT_CMDMODE variables
after parsing each option and by storing all relevant details if their
value changed. Do that whether or not the changing options has the flag
PARSE_OPT_CMDMODE set. Report an incompatibility only if two options
change the variable to different values and at least one of them is a
PARSE_OPT_CMDMODE option. This changes the output of the first three
examples above to:
$ t/helper/test-tool parse-options --set23 --mode1
error: --mode1 is incompatible with --set23
$ t/helper/test-tool parse-options --mode1 --set23
error: --set23 is incompatible with --mode1
$ git am --resolved --quit
error: --quit is incompatible with --resolved
Store the argument of PARSE_OPT_CMDMODE options of type OPTION_CALLBACK
as well to allow taking over the responsibility for compatibility
checking from the callback function. The next patch will use this
capability to fix the messages for git am --show-current-patch.
Use a linked list for storing the PARSE_OPT_CMDMODE variables. This
somewhat outdated data structure is simple and suffices, as the number
of elements per command is currently only zero or one. We do support
multiple different command modes variables per command, but I don't
expect that we'd ever use a significant number of them. Once we do we
can switch to a hashmap.
Since we no longer need to search the conflicting option, the all_opts
parameter of get_value() is no longer used. Remove it.
Extend the tests to check for both conflicting option names, but don't
insist on a particular order.
Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-10-28 11:53:01 +00:00
|
|
|
test_expect_success 'OPT_CMDMODE() detects incompatibility (1)' '
|
2020-02-20 14:15:15 +00:00
|
|
|
test_must_fail test-tool parse-options --mode1 --mode2 >output 2>output.err &&
|
|
|
|
test_must_be_empty output &&
|
2023-11-08 02:04:02 +00:00
|
|
|
test_grep "mode1" output.err &&
|
|
|
|
test_grep "mode2" output.err &&
|
2023-11-26 11:57:43 +00:00
|
|
|
test_grep "cannot be used together" output.err
|
2020-02-20 14:15:15 +00:00
|
|
|
'
|
|
|
|
|
parse-options: make CMDMODE errors more precise
Only a single PARSE_OPT_CMDMODE option can be specified for the same
variable at the same time. This is enforced by get_value(), but the
error messages are imprecise in three ways:
1. If a non-PARSE_OPT_CMDMODE option changes the value variable of a
PARSE_OPT_CMDMODE option then an ominously vague message is shown:
$ t/helper/test-tool parse-options --set23 --mode1
error: option `mode1' : incompatible with something else
Worse: If the order of options is reversed then no error is reported at
all:
$ t/helper/test-tool parse-options --mode1 --set23
boolean: 0
integer: 23
magnitude: 0
timestamp: 0
string: (not set)
abbrev: 7
verbose: -1
quiet: 0
dry run: no
file: (not set)
Fortunately this can currently only happen in the test helper; actual
Git commands don't share the same variable for the value of options with
and without the flag PARSE_OPT_CMDMODE.
2. If there are multiple options with the same value (synonyms), then
the one that is defined first is shown rather than the one actually
given on the command line, which is confusing:
$ git am --resolved --quit
error: option `quit' is incompatible with --continue
3. Arguments of PARSE_OPT_CMDMODE options are not handled by the
parse-option machinery. This is left to the callback function. We
currently only have a single affected option, --show-current-patch of
git am. Errors for it can show an argument that was not actually given
on the command line:
$ git am --show-current-patch --show-current-patch=diff
error: options '--show-current-patch=diff' and '--show-current-patch=raw' cannot be used together
The options --show-current-patch and --show-current-patch=raw are
synonyms, but the error accuses the user of input they did not actually
made. Or it can awkwardly print a NULL pointer:
$ git am --show-current-patch=diff --show-current-patch
error: options '--show-current-patch=(null)' and '--show-current-patch=diff' cannot be used together
The reasons for these shortcomings is that the current code checks
incompatibility only when encountering a PARSE_OPT_CMDMODE option at the
command line, and that it searches the previous incompatible option by
value.
Fix the first two points by checking all PARSE_OPT_CMDMODE variables
after parsing each option and by storing all relevant details if their
value changed. Do that whether or not the changing options has the flag
PARSE_OPT_CMDMODE set. Report an incompatibility only if two options
change the variable to different values and at least one of them is a
PARSE_OPT_CMDMODE option. This changes the output of the first three
examples above to:
$ t/helper/test-tool parse-options --set23 --mode1
error: --mode1 is incompatible with --set23
$ t/helper/test-tool parse-options --mode1 --set23
error: --set23 is incompatible with --mode1
$ git am --resolved --quit
error: --quit is incompatible with --resolved
Store the argument of PARSE_OPT_CMDMODE options of type OPTION_CALLBACK
as well to allow taking over the responsibility for compatibility
checking from the callback function. The next patch will use this
capability to fix the messages for git am --show-current-patch.
Use a linked list for storing the PARSE_OPT_CMDMODE variables. This
somewhat outdated data structure is simple and suffices, as the number
of elements per command is currently only zero or one. We do support
multiple different command modes variables per command, but I don't
expect that we'd ever use a significant number of them. Once we do we
can switch to a hashmap.
Since we no longer need to search the conflicting option, the all_opts
parameter of get_value() is no longer used. Remove it.
Extend the tests to check for both conflicting option names, but don't
insist on a particular order.
Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-10-28 11:53:01 +00:00
|
|
|
test_expect_success 'OPT_CMDMODE() detects incompatibility (2)' '
|
2020-02-20 14:15:15 +00:00
|
|
|
test_must_fail test-tool parse-options --set23 --mode2 >output 2>output.err &&
|
|
|
|
test_must_be_empty output &&
|
2023-11-08 02:04:02 +00:00
|
|
|
test_grep "mode2" output.err &&
|
|
|
|
test_grep "set23" output.err &&
|
2023-11-26 11:57:43 +00:00
|
|
|
test_grep "cannot be used together" output.err
|
parse-options: make CMDMODE errors more precise
Only a single PARSE_OPT_CMDMODE option can be specified for the same
variable at the same time. This is enforced by get_value(), but the
error messages are imprecise in three ways:
1. If a non-PARSE_OPT_CMDMODE option changes the value variable of a
PARSE_OPT_CMDMODE option then an ominously vague message is shown:
$ t/helper/test-tool parse-options --set23 --mode1
error: option `mode1' : incompatible with something else
Worse: If the order of options is reversed then no error is reported at
all:
$ t/helper/test-tool parse-options --mode1 --set23
boolean: 0
integer: 23
magnitude: 0
timestamp: 0
string: (not set)
abbrev: 7
verbose: -1
quiet: 0
dry run: no
file: (not set)
Fortunately this can currently only happen in the test helper; actual
Git commands don't share the same variable for the value of options with
and without the flag PARSE_OPT_CMDMODE.
2. If there are multiple options with the same value (synonyms), then
the one that is defined first is shown rather than the one actually
given on the command line, which is confusing:
$ git am --resolved --quit
error: option `quit' is incompatible with --continue
3. Arguments of PARSE_OPT_CMDMODE options are not handled by the
parse-option machinery. This is left to the callback function. We
currently only have a single affected option, --show-current-patch of
git am. Errors for it can show an argument that was not actually given
on the command line:
$ git am --show-current-patch --show-current-patch=diff
error: options '--show-current-patch=diff' and '--show-current-patch=raw' cannot be used together
The options --show-current-patch and --show-current-patch=raw are
synonyms, but the error accuses the user of input they did not actually
made. Or it can awkwardly print a NULL pointer:
$ git am --show-current-patch=diff --show-current-patch
error: options '--show-current-patch=(null)' and '--show-current-patch=diff' cannot be used together
The reasons for these shortcomings is that the current code checks
incompatibility only when encountering a PARSE_OPT_CMDMODE option at the
command line, and that it searches the previous incompatible option by
value.
Fix the first two points by checking all PARSE_OPT_CMDMODE variables
after parsing each option and by storing all relevant details if their
value changed. Do that whether or not the changing options has the flag
PARSE_OPT_CMDMODE set. Report an incompatibility only if two options
change the variable to different values and at least one of them is a
PARSE_OPT_CMDMODE option. This changes the output of the first three
examples above to:
$ t/helper/test-tool parse-options --set23 --mode1
error: --mode1 is incompatible with --set23
$ t/helper/test-tool parse-options --mode1 --set23
error: --set23 is incompatible with --mode1
$ git am --resolved --quit
error: --quit is incompatible with --resolved
Store the argument of PARSE_OPT_CMDMODE options of type OPTION_CALLBACK
as well to allow taking over the responsibility for compatibility
checking from the callback function. The next patch will use this
capability to fix the messages for git am --show-current-patch.
Use a linked list for storing the PARSE_OPT_CMDMODE variables. This
somewhat outdated data structure is simple and suffices, as the number
of elements per command is currently only zero or one. We do support
multiple different command modes variables per command, but I don't
expect that we'd ever use a significant number of them. Once we do we
can switch to a hashmap.
Since we no longer need to search the conflicting option, the all_opts
parameter of get_value() is no longer used. Remove it.
Extend the tests to check for both conflicting option names, but don't
insist on a particular order.
Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-10-28 11:53:01 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'OPT_CMDMODE() detects incompatibility (3)' '
|
|
|
|
test_must_fail test-tool parse-options --mode2 --set23 >output 2>output.err &&
|
|
|
|
test_must_be_empty output &&
|
2023-11-08 02:04:02 +00:00
|
|
|
test_grep "mode2" output.err &&
|
|
|
|
test_grep "set23" output.err &&
|
2023-11-26 11:57:43 +00:00
|
|
|
test_grep "cannot be used together" output.err
|
parse-options: make CMDMODE errors more precise
Only a single PARSE_OPT_CMDMODE option can be specified for the same
variable at the same time. This is enforced by get_value(), but the
error messages are imprecise in three ways:
1. If a non-PARSE_OPT_CMDMODE option changes the value variable of a
PARSE_OPT_CMDMODE option then an ominously vague message is shown:
$ t/helper/test-tool parse-options --set23 --mode1
error: option `mode1' : incompatible with something else
Worse: If the order of options is reversed then no error is reported at
all:
$ t/helper/test-tool parse-options --mode1 --set23
boolean: 0
integer: 23
magnitude: 0
timestamp: 0
string: (not set)
abbrev: 7
verbose: -1
quiet: 0
dry run: no
file: (not set)
Fortunately this can currently only happen in the test helper; actual
Git commands don't share the same variable for the value of options with
and without the flag PARSE_OPT_CMDMODE.
2. If there are multiple options with the same value (synonyms), then
the one that is defined first is shown rather than the one actually
given on the command line, which is confusing:
$ git am --resolved --quit
error: option `quit' is incompatible with --continue
3. Arguments of PARSE_OPT_CMDMODE options are not handled by the
parse-option machinery. This is left to the callback function. We
currently only have a single affected option, --show-current-patch of
git am. Errors for it can show an argument that was not actually given
on the command line:
$ git am --show-current-patch --show-current-patch=diff
error: options '--show-current-patch=diff' and '--show-current-patch=raw' cannot be used together
The options --show-current-patch and --show-current-patch=raw are
synonyms, but the error accuses the user of input they did not actually
made. Or it can awkwardly print a NULL pointer:
$ git am --show-current-patch=diff --show-current-patch
error: options '--show-current-patch=(null)' and '--show-current-patch=diff' cannot be used together
The reasons for these shortcomings is that the current code checks
incompatibility only when encountering a PARSE_OPT_CMDMODE option at the
command line, and that it searches the previous incompatible option by
value.
Fix the first two points by checking all PARSE_OPT_CMDMODE variables
after parsing each option and by storing all relevant details if their
value changed. Do that whether or not the changing options has the flag
PARSE_OPT_CMDMODE set. Report an incompatibility only if two options
change the variable to different values and at least one of them is a
PARSE_OPT_CMDMODE option. This changes the output of the first three
examples above to:
$ t/helper/test-tool parse-options --set23 --mode1
error: --mode1 is incompatible with --set23
$ t/helper/test-tool parse-options --mode1 --set23
error: --set23 is incompatible with --mode1
$ git am --resolved --quit
error: --quit is incompatible with --resolved
Store the argument of PARSE_OPT_CMDMODE options of type OPTION_CALLBACK
as well to allow taking over the responsibility for compatibility
checking from the callback function. The next patch will use this
capability to fix the messages for git am --show-current-patch.
Use a linked list for storing the PARSE_OPT_CMDMODE variables. This
somewhat outdated data structure is simple and suffices, as the number
of elements per command is currently only zero or one. We do support
multiple different command modes variables per command, but I don't
expect that we'd ever use a significant number of them. Once we do we
can switch to a hashmap.
Since we no longer need to search the conflicting option, the all_opts
parameter of get_value() is no longer used. Remove it.
Extend the tests to check for both conflicting option names, but don't
insist on a particular order.
Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-10-28 11:53:01 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'OPT_CMDMODE() detects incompatibility (4)' '
|
|
|
|
test_must_fail test-tool parse-options --mode2 --mode34=3 \
|
|
|
|
>output 2>output.err &&
|
|
|
|
test_must_be_empty output &&
|
2023-11-08 02:04:02 +00:00
|
|
|
test_grep "mode2" output.err &&
|
|
|
|
test_grep "mode34.3" output.err &&
|
2023-11-26 11:57:43 +00:00
|
|
|
test_grep "cannot be used together" output.err
|
2020-02-20 14:15:15 +00:00
|
|
|
'
|
|
|
|
|
2012-02-25 19:11:16 +00:00
|
|
|
test_expect_success 'OPT_COUNTUP() with PARSE_OPT_NODASH works' '
|
2018-09-09 17:36:29 +00:00
|
|
|
test-tool parse-options --expect="boolean: 6" + + + + + +
|
2009-05-07 19:45:42 +00:00
|
|
|
'
|
|
|
|
|
2009-05-07 19:45:08 +00:00
|
|
|
test_expect_success 'OPT_NUMBER_CALLBACK() works' '
|
2018-09-09 17:36:29 +00:00
|
|
|
test-tool parse-options --expect="integer: 12345" -12345
|
2009-05-07 19:45:08 +00:00
|
|
|
'
|
|
|
|
|
2016-04-12 23:02:17 +00:00
|
|
|
cat >expect <<\EOF
|
2009-09-25 18:44:44 +00:00
|
|
|
boolean: 0
|
|
|
|
integer: 0
|
2015-06-21 18:25:44 +00:00
|
|
|
magnitude: 0
|
2009-09-25 18:44:44 +00:00
|
|
|
timestamp: 0
|
|
|
|
string: (not set)
|
|
|
|
abbrev: 7
|
parse-options.c: make OPTION_COUNTUP respect "unspecified" values
OPT_COUNTUP() merely increments the counter upon --option, and resets it
to 0 upon --no-option, which means that there is no "unspecified" value
with which a client can initialize the counter to determine whether or
not --[no]-option was seen at all.
Make OPT_COUNTUP() treat any negative number as an "unspecified" value
to address this shortcoming. In particular, if a client initializes the
counter to -1, then if it is still -1 after parse_options(), then
neither --option nor --no-option was seen; if it is 0, then --no-option
was seen last, and if it is 1 or greater, than --option was seen last.
This change does not affect the behavior of existing clients because
they all use the initial value of 0 (or more).
Note that builtin/clean.c initializes the variable used with
OPT__FORCE (which uses OPT_COUNTUP()) to a negative value, but it is set
to either 0 or 1 by reading the configuration before the code calls
parse_options(), i.e. as far as parse_options() is concerned, the
initial value of the variable is not negative.
To test this behavior, in test-parse-options.c, "verbose" is set to
"unspecified" while quiet is set to 0 which will test the new behavior
with all sets of values.
Helped-by: Jeff King <peff@peff.net>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-05 09:50:00 +00:00
|
|
|
verbose: -1
|
2016-04-12 23:02:17 +00:00
|
|
|
quiet: 0
|
2009-09-25 18:44:44 +00:00
|
|
|
dry run: no
|
|
|
|
file: (not set)
|
|
|
|
EOF
|
|
|
|
|
|
|
|
test_expect_success 'negation of OPT_NONEG flags is not ambiguous' '
|
tests: disallow the use of abbreviated options (by default)
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` expanded to `git init --bare`, that future
contribution would now have to touch seemingly unrelated tests just to
keep the test suite from failing.
So let's disallow abbreviated options in the test suite by default.
Note: for ease of implementation, this patch really only touches the
`parse-options` machinery: more and more hand-rolled option parsers are
converted to use that internal API, and more and more scripts are
converted to built-ins (naturally using the parse-options API, too), so
in practice this catches most issues, and is definitely the biggest bang
for the buck.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-12 09:37:24 +00:00
|
|
|
GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS=false \
|
2018-09-09 17:36:29 +00:00
|
|
|
test-tool parse-options --no-ambig >output 2>output.err &&
|
2013-06-09 18:29:20 +00:00
|
|
|
test_must_be_empty output.err &&
|
2009-09-25 18:44:44 +00:00
|
|
|
test_cmp expect output
|
|
|
|
'
|
|
|
|
|
2016-04-12 23:02:17 +00:00
|
|
|
cat >>expect <<\EOF
|
2011-06-09 15:55:23 +00:00
|
|
|
list: foo
|
|
|
|
list: bar
|
|
|
|
list: baz
|
|
|
|
EOF
|
|
|
|
test_expect_success '--list keeps list of strings' '
|
2018-09-09 17:36:29 +00:00
|
|
|
test-tool parse-options --list foo --list=bar --list=baz >output &&
|
2011-06-09 15:55:23 +00:00
|
|
|
test_cmp expect output
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--no-list resets list' '
|
2018-09-09 17:36:29 +00:00
|
|
|
test-tool parse-options --list=other --list=irrelevant --list=options \
|
2011-06-09 15:55:23 +00:00
|
|
|
--no-list --list=foo --list=bar --list=baz >output &&
|
|
|
|
test_cmp expect output
|
|
|
|
'
|
|
|
|
|
2016-05-05 09:49:58 +00:00
|
|
|
test_expect_success 'multiple quiet levels' '
|
2018-09-09 17:36:29 +00:00
|
|
|
test-tool parse-options --expect="quiet: 3" -q -q -q
|
2016-05-05 09:49:58 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'multiple verbose levels' '
|
2018-09-09 17:36:29 +00:00
|
|
|
test-tool parse-options --expect="verbose: 3" -v -v -v
|
2016-05-05 09:49:58 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--no-quiet sets --quiet to 0' '
|
2018-09-09 17:36:29 +00:00
|
|
|
test-tool parse-options --expect="quiet: 0" --no-quiet
|
2016-05-05 09:49:58 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--no-quiet resets multiple -q to 0' '
|
2018-09-09 17:36:29 +00:00
|
|
|
test-tool parse-options --expect="quiet: 0" -q -q -q --no-quiet
|
2016-05-05 09:49:58 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--no-verbose sets verbose to 0' '
|
2018-09-09 17:36:29 +00:00
|
|
|
test-tool parse-options --expect="verbose: 0" --no-verbose
|
2016-05-05 09:49:58 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--no-verbose resets multiple verbose to 0' '
|
2018-09-09 17:36:29 +00:00
|
|
|
test-tool parse-options --expect="verbose: 0" -v -v -v --no-verbose
|
2016-05-05 09:49:58 +00:00
|
|
|
'
|
|
|
|
|
tests: disallow the use of abbreviated options (by default)
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` expanded to `git init --bare`, that future
contribution would now have to touch seemingly unrelated tests just to
keep the test suite from failing.
So let's disallow abbreviated options in the test suite by default.
Note: for ease of implementation, this patch really only touches the
`parse-options` machinery: more and more hand-rolled option parsers are
converted to use that internal API, and more and more scripts are
converted to built-ins (naturally using the parse-options API, too), so
in practice this catches most issues, and is definitely the biggest bang
for the buck.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-12 09:37:24 +00:00
|
|
|
test_expect_success 'GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS works' '
|
|
|
|
GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS=false \
|
|
|
|
test-tool parse-options --ye &&
|
|
|
|
test_must_fail env GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS=true \
|
|
|
|
test-tool parse-options --ye
|
|
|
|
'
|
|
|
|
|
2019-08-06 14:40:16 +00:00
|
|
|
test_expect_success '--end-of-options treats remainder as args' '
|
|
|
|
test-tool parse-options \
|
|
|
|
--expect="verbose: -1" \
|
|
|
|
--expect="arg 00: --verbose" \
|
|
|
|
--end-of-options --verbose
|
|
|
|
'
|
|
|
|
|
2022-08-19 16:03:55 +00:00
|
|
|
test_expect_success 'KEEP_DASHDASH works' '
|
|
|
|
test-tool parse-options-flags --keep-dashdash cmd --opt=1 -- --opt=2 --unknown >actual &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
opt: 1
|
|
|
|
arg 00: --
|
|
|
|
arg 01: --opt=2
|
|
|
|
arg 02: --unknown
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'KEEP_ARGV0 works' '
|
|
|
|
test-tool parse-options-flags --keep-argv0 cmd arg0 --opt=3 >actual &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
opt: 3
|
|
|
|
arg 00: cmd
|
|
|
|
arg 01: arg0
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'STOP_AT_NON_OPTION works' '
|
|
|
|
test-tool parse-options-flags --stop-at-non-option cmd --opt=4 arg0 --opt=5 --unknown >actual &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
opt: 4
|
|
|
|
arg 00: arg0
|
|
|
|
arg 01: --opt=5
|
|
|
|
arg 02: --unknown
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2022-08-19 16:03:57 +00:00
|
|
|
test_expect_success 'KEEP_UNKNOWN_OPT works' '
|
|
|
|
test-tool parse-options-flags --keep-unknown-opt cmd --unknown=1 --opt=6 -u2 >actual &&
|
2022-08-19 16:03:55 +00:00
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
opt: 6
|
|
|
|
arg 00: --unknown=1
|
|
|
|
arg 01: -u2
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'NO_INTERNAL_HELP works for -h' '
|
|
|
|
test_expect_code 129 test-tool parse-options-flags --no-internal-help cmd -h 2>err &&
|
|
|
|
grep "^error: unknown switch \`h$SQ" err &&
|
|
|
|
grep "^usage: " err
|
|
|
|
'
|
|
|
|
|
|
|
|
for help_opt in help help-all
|
|
|
|
do
|
|
|
|
test_expect_success "NO_INTERNAL_HELP works for --$help_opt" "
|
|
|
|
test_expect_code 129 test-tool parse-options-flags --no-internal-help cmd --$help_opt 2>err &&
|
|
|
|
grep '^error: unknown option \`'$help_opt\' err &&
|
|
|
|
grep '^usage: ' err
|
|
|
|
"
|
|
|
|
done
|
|
|
|
|
2022-08-19 16:03:57 +00:00
|
|
|
test_expect_success 'KEEP_UNKNOWN_OPT | NO_INTERNAL_HELP works' '
|
|
|
|
test-tool parse-options-flags --keep-unknown-opt --no-internal-help cmd -h --help --help-all >actual &&
|
2022-08-19 16:03:55 +00:00
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
opt: 0
|
|
|
|
arg 00: -h
|
|
|
|
arg 01: --help
|
|
|
|
arg 02: --help-all
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
parse-options: add support for parsing subcommands
Several Git commands have subcommands to implement mutually exclusive
"operation modes", and they usually parse their subcommand argument
with a bunch of if-else if statements.
Teach parse-options to handle subcommands as well, which will result
in shorter and simpler code with consistent error handling and error
messages on unknown or missing subcommand, and it will also make
possible for our Bash completion script to handle subcommands
programmatically.
The approach is guided by the following observations:
- Most subcommands [1] are implemented in dedicated functions, and
most of those functions [2] either have a signature matching the
'int cmd_foo(int argc, const char **argc, const char *prefix)'
signature of builtin commands or can be trivially converted to
that signature, because they miss only that last prefix parameter
or have no parameters at all.
- Subcommand arguments only have long form, and they have no double
dash prefix, no negated form, and no description, and they don't
take any arguments, and can't be abbreviated.
- There must be exactly one subcommand among the arguments, or zero
if the command has a default operation mode.
- All arguments following the subcommand are considered to be
arguments of the subcommand, and, conversely, arguments meant for
the subcommand may not preceed the subcommand.
So in the end subcommand declaration and parsing would look something
like this:
parse_opt_subcommand_fn *fn = NULL;
struct option builtin_commit_graph_options[] = {
OPT_STRING(0, "object-dir", &opts.obj_dir, N_("dir"),
N_("the object directory to store the graph")),
OPT_SUBCOMMAND("verify", &fn, graph_verify),
OPT_SUBCOMMAND("write", &fn, graph_write),
OPT_END(),
};
argc = parse_options(argc, argv, prefix, options,
builtin_commit_graph_usage, 0);
return fn(argc, argv, prefix);
Here each OPT_SUBCOMMAND specifies the name of the subcommand and the
function implementing it, and the address of the same 'fn' subcommand
function pointer. parse_options() then processes the arguments until
it finds the first argument matching one of the subcommands, sets 'fn'
to the function associated with that subcommand, and returns, leaving
the rest of the arguments unprocessed. If none of the listed
subcommands is found among the arguments, parse_options() will show
usage and abort.
If a command has a default operation mode, 'fn' should be initialized
to the function implementing that mode, and parse_options() should be
invoked with the PARSE_OPT_SUBCOMMAND_OPTIONAL flag. In this case
parse_options() won't error out when not finding any subcommands, but
will return leaving 'fn' unchanged. Note that if that default
operation mode has any --options, then the PARSE_OPT_KEEP_UNKNOWN_OPT
flag is necessary as well (otherwise parse_options() would error out
upon seeing the unknown option meant to the default operation mode).
Some thoughts about the implementation:
- The same pointer to 'fn' must be specified as 'value' for each
OPT_SUBCOMMAND, because there can be only one set of mutually
exclusive subcommands; parse_options() will BUG() otherwise.
There are other ways to tell parse_options() where to put the
function associated with the subcommand given on the command line,
but I didn't like them:
- Change parse_options()'s signature by adding a pointer to
subcommand function to be set to the function associated with
the given subcommand, affecting all callsites, even those that
don't have subcommands.
- Introduce a specific parse_options_and_subcommand() variant
with that extra funcion parameter.
- I decided against automatically calling the subcommand function
from within parse_options(), because:
- There are commands that have to perform additional actions
after option parsing but before calling the function
implementing the specified subcommand.
- The return code of the subcommand is usually the return code
of the git command, but preserving the return code of the
automatically called subcommand function would have made the
API awkward.
- Also add a OPT_SUBCOMMAND_F() variant to allow specifying an
option flag: we have two subcommands that are purposefully
excluded from completion ('git remote rm' and 'git stash save'),
so they'll have to be specified with the PARSE_OPT_NOCOMPLETE
flag.
- Some of the 'parse_opt_flags' don't make sense with subcommands,
and using them is probably just an oversight or misunderstanding.
Therefore parse_options() will BUG() when invoked with any of the
following flags while the options array contains at least one
OPT_SUBCOMMAND:
- PARSE_OPT_KEEP_DASHDASH: parse_options() stops parsing
arguments when encountering a "--" argument, so it doesn't
make sense to expect and keep one before a subcommand, because
it would prevent the parsing of the subcommand.
However, this flag is allowed in combination with the
PARSE_OPT_SUBCOMMAND_OPTIONAL flag, because the double dash
might be meaningful for the command's default operation mode,
e.g. to disambiguate refs and pathspecs.
- PARSE_OPT_STOP_AT_NON_OPTION: As its name suggests, this flag
tells parse_options() to stop as soon as it encouners a
non-option argument, but subcommands are by definition not
options... so how could they be parsed, then?!
- PARSE_OPT_KEEP_UNKNOWN: This flag can be used to collect any
unknown --options and then pass them to a different command or
subsystem. Surely if a command has subcommands, then this
functionality should rather be delegated to one of those
subcommands, and not performed by the command itself.
However, this flag is allowed in combination with the
PARSE_OPT_SUBCOMMAND_OPTIONAL flag, making possible to pass
--options to the default operation mode.
- If the command with subcommands has a default operation mode, then
all arguments to the command must preceed the arguments of the
subcommand.
AFAICT we don't have any commands where this makes a difference,
because in those commands either only the command accepts any
arguments ('notes' and 'remote'), or only the default subcommand
('reflog' and 'stash'), but never both.
- The 'argv' array passed to subcommand functions currently starts
with the name of the subcommand. Keep this behavior. AFAICT no
subcommand functions depend on the actual content of 'argv[0]',
but the parse_options() call handling their options expects that
the options start at argv[1].
- To support handling subcommands programmatically in our Bash
completion script, 'git cmd --git-completion-helper' will now list
both subcommands and regular --options, if any. This means that
the completion script will have to separate subcommands (i.e.
words without a double dash prefix) from --options on its own, but
that's rather easy to do, and it's not much work either, because
the number of subcommands a command might have is rather low, and
those commands accept only a single --option or none at all. An
alternative would be to introduce a separate option that lists
only subcommands, but then the completion script would need not
one but two git invocations and command substitutions for commands
with subcommands.
Note that this change doesn't affect the behavior of our Bash
completion script, because when completing the --option of a
command with subcommands, e.g. for 'git notes --<TAB>', then all
subcommands will be filtered out anyway, as none of them will
match the word to be completed starting with that double dash
prefix.
[1] Except 'git rerere', because many of its subcommands are
implemented in the bodies of the if-else if statements parsing the
command's subcommand argument.
[2] Except 'credential', 'credential-store' and 'fsmonitor--daemon',
because some of the functions implementing their subcommands take
special parameters.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-19 16:04:00 +00:00
|
|
|
test_expect_success 'subcommand - no subcommand shows error and usage' '
|
|
|
|
test_expect_code 129 test-tool parse-subcommand cmd 2>err &&
|
|
|
|
grep "^error: need a subcommand" err &&
|
|
|
|
grep ^usage: err
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'subcommand - subcommand after -- shows error and usage' '
|
|
|
|
test_expect_code 129 test-tool parse-subcommand cmd -- subcmd-one 2>err &&
|
|
|
|
grep "^error: need a subcommand" err &&
|
|
|
|
grep ^usage: err
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'subcommand - subcommand after --end-of-options shows error and usage' '
|
|
|
|
test_expect_code 129 test-tool parse-subcommand cmd --end-of-options subcmd-one 2>err &&
|
|
|
|
grep "^error: need a subcommand" err &&
|
|
|
|
grep ^usage: err
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'subcommand - unknown subcommand shows error and usage' '
|
|
|
|
test_expect_code 129 test-tool parse-subcommand cmd nope 2>err &&
|
|
|
|
grep "^error: unknown subcommand: \`nope$SQ" err &&
|
|
|
|
grep ^usage: err
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'subcommand - subcommands cannot be abbreviated' '
|
|
|
|
test_expect_code 129 test-tool parse-subcommand cmd subcmd-o 2>err &&
|
|
|
|
grep "^error: unknown subcommand: \`subcmd-o$SQ$" err &&
|
|
|
|
grep ^usage: err
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'subcommand - no negated subcommands' '
|
|
|
|
test_expect_code 129 test-tool parse-subcommand cmd no-subcmd-one 2>err &&
|
|
|
|
grep "^error: unknown subcommand: \`no-subcmd-one$SQ" err &&
|
|
|
|
grep ^usage: err
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'subcommand - simple' '
|
|
|
|
test-tool parse-subcommand cmd subcmd-two >actual &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
opt: 0
|
|
|
|
fn: subcmd_two
|
|
|
|
arg 00: subcmd-two
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'subcommand - stop parsing at the first subcommand' '
|
|
|
|
test-tool parse-subcommand cmd --opt=1 subcmd-two subcmd-one --opt=2 >actual &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
opt: 1
|
|
|
|
fn: subcmd_two
|
|
|
|
arg 00: subcmd-two
|
|
|
|
arg 01: subcmd-one
|
|
|
|
arg 02: --opt=2
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'subcommand - KEEP_ARGV0' '
|
|
|
|
test-tool parse-subcommand --keep-argv0 cmd subcmd-two >actual &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
opt: 0
|
|
|
|
fn: subcmd_two
|
|
|
|
arg 00: cmd
|
|
|
|
arg 01: subcmd-two
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'subcommand - SUBCOMMAND_OPTIONAL + subcommand not given' '
|
|
|
|
test-tool parse-subcommand --subcommand-optional cmd >actual &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
opt: 0
|
|
|
|
fn: subcmd_one
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'subcommand - SUBCOMMAND_OPTIONAL + given subcommand' '
|
|
|
|
test-tool parse-subcommand --subcommand-optional cmd subcmd-two branch file >actual &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
opt: 0
|
|
|
|
fn: subcmd_two
|
|
|
|
arg 00: subcmd-two
|
|
|
|
arg 01: branch
|
|
|
|
arg 02: file
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'subcommand - SUBCOMMAND_OPTIONAL + subcommand not given + unknown dashless args' '
|
|
|
|
test-tool parse-subcommand --subcommand-optional cmd branch file >actual &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
opt: 0
|
|
|
|
fn: subcmd_one
|
|
|
|
arg 00: branch
|
|
|
|
arg 01: file
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'subcommand - SUBCOMMAND_OPTIONAL + subcommand not given + unknown option' '
|
|
|
|
test_expect_code 129 test-tool parse-subcommand --subcommand-optional cmd --subcommand-opt 2>err &&
|
|
|
|
grep "^error: unknown option" err &&
|
|
|
|
grep ^usage: err
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'subcommand - SUBCOMMAND_OPTIONAL | KEEP_UNKNOWN_OPT + subcommand not given + unknown option' '
|
|
|
|
test-tool parse-subcommand --subcommand-optional --keep-unknown-opt cmd --subcommand-opt >actual &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
opt: 0
|
|
|
|
fn: subcmd_one
|
|
|
|
arg 00: --subcommand-opt
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'subcommand - SUBCOMMAND_OPTIONAL | KEEP_UNKNOWN_OPT + subcommand ignored after unknown option' '
|
|
|
|
test-tool parse-subcommand --subcommand-optional --keep-unknown-opt cmd --subcommand-opt subcmd-two >actual &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
opt: 0
|
|
|
|
fn: subcmd_one
|
|
|
|
arg 00: --subcommand-opt
|
|
|
|
arg 01: subcmd-two
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'subcommand - SUBCOMMAND_OPTIONAL | KEEP_UNKNOWN_OPT + command and subcommand options cannot be mixed' '
|
|
|
|
test-tool parse-subcommand --subcommand-optional --keep-unknown-opt cmd --subcommand-opt branch --opt=1 >actual &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
opt: 0
|
|
|
|
fn: subcmd_one
|
|
|
|
arg 00: --subcommand-opt
|
|
|
|
arg 01: branch
|
|
|
|
arg 02: --opt=1
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'subcommand - SUBCOMMAND_OPTIONAL | KEEP_UNKNOWN_OPT | KEEP_ARGV0' '
|
|
|
|
test-tool parse-subcommand --subcommand-optional --keep-unknown-opt --keep-argv0 cmd --subcommand-opt branch >actual &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
opt: 0
|
|
|
|
fn: subcmd_one
|
|
|
|
arg 00: cmd
|
|
|
|
arg 01: --subcommand-opt
|
|
|
|
arg 02: branch
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'subcommand - SUBCOMMAND_OPTIONAL | KEEP_UNKNOWN_OPT | KEEP_DASHDASH' '
|
|
|
|
test-tool parse-subcommand --subcommand-optional --keep-unknown-opt --keep-dashdash cmd -- --subcommand-opt file >actual &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
opt: 0
|
|
|
|
fn: subcmd_one
|
|
|
|
arg 00: --
|
|
|
|
arg 01: --subcommand-opt
|
|
|
|
arg 02: file
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'subcommand - completion helper' '
|
|
|
|
test-tool parse-subcommand cmd --git-completion-helper >actual &&
|
|
|
|
echo "subcmd-one subcmd-two --opt= --no-opt" >expect &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'subcommands are incompatible with STOP_AT_NON_OPTION' '
|
|
|
|
test_must_fail test-tool parse-subcommand --stop-at-non-option cmd subcmd-one 2>err &&
|
|
|
|
grep ^BUG err
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'subcommands are incompatible with KEEP_UNKNOWN_OPT unless in combination with SUBCOMMAND_OPTIONAL' '
|
|
|
|
test_must_fail test-tool parse-subcommand --keep-unknown-opt cmd subcmd-two 2>err &&
|
|
|
|
grep ^BUG err
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'subcommands are incompatible with KEEP_DASHDASH unless in combination with SUBCOMMAND_OPTIONAL' '
|
|
|
|
test_must_fail test-tool parse-subcommand --keep-dashdash cmd subcmd-two 2>err &&
|
|
|
|
grep ^BUG err
|
|
|
|
'
|
|
|
|
|
2022-11-09 14:16:26 +00:00
|
|
|
test_expect_success 'negative magnitude' '
|
|
|
|
test_must_fail test-tool parse-options --magnitude -1 >out 2>err &&
|
|
|
|
grep "non-negative integer" err &&
|
|
|
|
test_must_be_empty out
|
|
|
|
'
|
2022-11-09 14:16:27 +00:00
|
|
|
|
|
|
|
test_expect_success 'magnitude with units but no numbers' '
|
|
|
|
test_must_fail test-tool parse-options --magnitude m >out 2>err &&
|
|
|
|
grep "non-negative integer" err &&
|
|
|
|
test_must_be_empty out
|
|
|
|
'
|
|
|
|
|
2007-10-13 16:34:45 +00:00
|
|
|
test_done
|