Re: [PATCH] ls-tree: fix --no-full-name

Am 21.07.23 um 22:09 schrieb Junio C Hamano:

René Scharfe [off-list ref] writes:

quoted

-    -D, --no-doubt        begins with 'no-'
+    -D, --[no-]no-doubt   begins with 'no-'

Hmph, I really really loved the neat trick to allow "no-doubt"
option to be "positivised" by _dropping_ the leading "no-" at around
0f1930c5 (parse-options: allow positivation of options starting,
with no-, 2012-02-25).

Yeah, if there is a better way to document A) that the "no-" is optional
and B) whether it's present by default, I'm all ears.

Many of the above are amusing and served as good demonstration to
show the blast radius, but it seems that most of them should be
marked with PARSE_OPT_NONEG.

Hard to say for me -- these are synthetic test cases and I lack context
to make that decision.  In t0040 (t/helper/test-parse-options.c rather)
we do have a few PARSE_OPT_NONEG uses already.  In t1502 we need to add
some...

quoted

diff --git a/t/t1502-rev-parse-parseopt.sh b/t/t1502-rev-parse-parseopt.sh
index dd811b7fb4..0a67e2dd4f 100755
--- a/t/t1502-rev-parse-parseopt.sh
+++ b/t/t1502-rev-parse-parseopt.sh

@@ -64,33 +64,38 @@ test_expect_success 'test --parseopt help output' '
 |
 |    some-command does foo and bar!
 |
-|    -h, --help            show the help
-|    --foo                 some nifty option --foo
-|    --bar ...             some cool option --bar with an argument
-|    -b, --baz             a short and long option
+|    -h, --[no-]help       show the help

Indeed it is amusing, but we probably should give PARSE_OPT_NONEG
appropriately, instead of changing the expectations, for many of the
changes we see here, I think.

... and --help is the one obvious choice for me, because --no-help is
not supported, of course.  But we can use some more dedicated tests of
negation and double-negation.

René