René Scharfe [off-list ref] writes:

Since 61fdbcf98b (ls-tree: migrate to parse-options, 2009-11-13) git
ls-tree has accepted the option --no-full-name, but it does the same
as --full-name, contrary to convention.  That's because it's defined
using OPT_SET_INT with a value of 0, where the negative variant sets
0 as well.

Ouch.  Well spotted.

Turn --no-full-name into the opposite of --full-name by using OPT_BOOL
instead and storing the option's status directly in a variable named
"full_name" instead of in negated form in "chomp_prefix".

Good solution, especially the flipping of the polarity of the
variable is very sensible.

I wonder if there are cases where it makes sense to allow the
"--no-" variant to an option parsed with OPT_SET_INT() that sets '0'
as the value?

Some random findings while reading hits from "git grep OPT_SET_INT":

 * "git am --[no-]keep-cr" is implemented as a pair of explicit
   PARSE_OPT_NONEG entries in the option[] array, but wouldn't it be
   sufficient to have a single OPT_SET_INT("keep-cr")?

 * "git branch --list --no-all" is accepted, sets filter.kind to 0,
   and triggers "fatal: filter_refs: invalid type".  Shouldn't we
   detect error much earlier?

 * "git bundle create --no-quiet" is accepted and sets the progress
   variable to 0, just like "--quiet" does, which is the same issue
   as the one fixed by your patch.

 * "git clone (--no-ipv4|--no-ipv6)" are accepted and uses
   TRANSPORT_FAMILY_ALL, presumably allowing both v4 and v6.
   Shouldn't we reject these?  "fetch" and "push" share the same
   issue.

 * "git status --no-(short|long|porcelain)" are accepted and use
   STATUS_FORMAT_NONE, which probably is OK.

 * "git commit --[no-](short|long|porcelain)" are accepted and
   behave as "git status" without doing any "git commit" thing,
   which should be corrected, I think.

 * "git describe --no-exact-match" is the same as "--exact-match",
   which is the same issue as the one fixed by your patch.

 * "git remote add" has an OPT_SET_INT() entry whose short and long
   forms are (0, NULL).  What is this supposed to do?  Shouldn't
   parse-options.c:parse_options_check() notice it as an error?

 * "git reset --(soft|hard|mixed|merge|keep)" all take the negated
   form and they all become "--mixed".  It may make sense to give
   all of them PARSE_OPT_NONEG.

 * "git show-branch --no-sparse" is the same as "--sparse",
   which is the same issue as the one fixed by your patch.

 * "git show-branch --no-topo-order" is the same as "--topo-order";
   as it is the default, we probably should give PARSE_OPT_NONEG.

 * "git show-branch --no-date-order" is the same as "--topo-order",
   which does sort-of make sense.  This (and the previous one)
   relies on REV_SORT_IN_GRAPH_ORDER enum being 0, which smells a
   bit brittle.

 * "git stash push --no-all" is the same as "--no-include-untracked",
   which smells iffy but probably is OK.

Anyway, the patch looks good.  Will queue.

Thanks.