From: "René Scharfe" <l.s.r@web.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [PATCH] ls-tree: fix --no-full-name
Date: Fri, 28 Jul 2023 08:12:39 +0200 [thread overview]
Message-ID: <a19879db-d45a-ee42-1ad5-497e4e9eb8df@web.de> (raw)
In-Reply-To: <xmqqh6ptnies.fsf@gitster.g>
Am 24.07.23 um 22:50 schrieb Junio C Hamano:
> René Scharfe <l.s.r@web.de> writes:
>
>> Am 24.07.23 um 20:51 schrieb Junio C Hamano:
>>> René Scharfe <l.s.r@web.de> writes:
>>>
>>>> Am 21.07.23 um 22:09 schrieb Junio C Hamano:
>>>>> René Scharfe <l.s.r@web.de> writes:
>>>>>
>>>>>> - -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.
>>>
>>> Some options take "no-" prefix while some others do not, so
>>> indicating that "this can take negative forms" vs "this do not take
>>> negative forms" by "--[no-]xyzzy" and "--frotz" makes sense.
>>>
>>> Yikes. There are tons of options whose names begin with "no-" and
>>> marked PARSE_OPT_NONEG, so "an option '--no-nitfol' that does not
>>> have the 'no-' part in [brackets] can drop 'no-' to make it
>>> positive" would not fly as a rule/convention.
>>>
>>> If we do not mind getting longer, we could say
>>>
>>> -D, --no-doubt, --doubt
>>>
>>> and explain in the description that --no-doubt is the same as -D and
>>> --doubt is the default. It is making the developers responsible for
>>> clarify, which is not very satisfying.
>>
>> Adjusting all explanations manually seems quite tedious.
>>
>>> We may not reject "--no-no-doubt" but with the positivization
>>> support, double negation is not something we'd encourage without
>>> feeling embarrassed.
>>
>> Right. Perhaps --[[no-]no-]doubt? Looks a bit silly with its nested
>> brackets, but it's more correct, because it documents all three accepted
>> forms, including the no-less one.
>
> It may look a bit silly but looks very tempting. Also it is not
> much longer than "--[no-]no-doubt".
Yes, it's quite compact. But is it they still legible?
--no-index find in contents not managed by git
--[no-]no-index find in contents not managed by git
--[[no-]no-]index find in contents not managed by git
--[no-[no-]]index find in contents not managed by git
The last two document all three variants, but is it still obvious that
the help text is supposed to be about the one with a single "no-"?
That's something that has to be learned, I suspect. No good making the
short help too cryptic. Hmm, how about:
--no-index, --[no-[no-]]index
find in contents not managed by git
Somewhat redundant, but highlights the documented variant.
René
next prev parent reply other threads:[~2023-07-28 6:12 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-18 15:44 [PATCH] ls-tree: fix --no-full-name René Scharfe
2023-07-18 16:37 ` Junio C Hamano
2023-07-18 20:49 ` Junio C Hamano
2023-07-21 12:41 ` René Scharfe
2023-07-21 12:41 ` René Scharfe
2023-07-21 14:37 ` Junio C Hamano
2023-07-21 19:29 ` René Scharfe
2023-07-21 20:09 ` Junio C Hamano
2023-07-21 20:14 ` Junio C Hamano
2023-07-24 12:29 ` René Scharfe
2023-07-24 18:51 ` Junio C Hamano
2023-07-24 20:09 ` René Scharfe
2023-07-24 20:50 ` Junio C Hamano
2023-07-28 6:12 ` René Scharfe [this message]
2023-07-28 9:45 ` Phillip Wood
2023-07-29 20:40 ` René Scharfe
2023-07-31 15:31 ` Junio C Hamano
2023-08-04 16:40 ` Junio C Hamano
2023-08-04 19:48 ` Phillip Wood
2023-08-05 10:40 ` René Scharfe
2023-07-24 12:29 ` [PATCH v2 0/5] show negatability of options in short help René Scharfe
2023-07-24 12:34 ` [PATCH v2 1/5] subtree: disallow --no-{help,quiet,debug,branch,message} René Scharfe
2023-07-24 12:36 ` [PATCH v2 2/5] t1502, docs: disallow --no-help René Scharfe
2023-07-24 12:38 ` [PATCH v2 3/5] t1502: move optionspec help output to a file René Scharfe
2023-07-24 12:39 ` [PATCH v2 4/5] t1502: test option negation René Scharfe
2023-07-24 12:40 ` [PATCH v2 5/5] parse-options: show negatability of options in short help René Scharfe
2023-08-05 14:33 ` [PATCH v3 0/8] " René Scharfe
2023-08-05 14:37 ` [PATCH v3 1/8] subtree: disallow --no-{help,quiet,debug,branch,message} René Scharfe
2023-08-05 14:37 ` [PATCH v3 2/8] t1502, docs: disallow --no-help René Scharfe
2023-08-05 14:38 ` [PATCH v3 3/8] t1502: move optionspec help output to a file René Scharfe
2023-08-05 14:39 ` [PATCH v3 4/8] t1502: test option negation René Scharfe
2023-08-05 14:40 ` [PATCH v3 5/8] parse-options: show negatability of options in short help René Scharfe
2023-08-05 14:43 ` [PATCH v3 6/8] parse-options: factor out usage_indent() and usage_padding() René Scharfe
2023-08-05 14:44 ` [PATCH v3 7/8] parse-options: no --[no-]no- René Scharfe
2023-08-05 14:52 ` [PATCH v3 8/8] parse-options: simplify usage_padding() René Scharfe
2023-08-05 23:04 ` Junio C Hamano
2023-07-21 12:41 ` [PATCH] show-branch: fix --no-sparse René Scharfe
2023-07-21 14:42 ` Junio C Hamano
2023-07-21 16:30 ` René Scharfe
2023-07-21 12:41 ` [PATCH] show-branch: disallow --no-{date,topo}-order René Scharfe
2023-07-21 12:41 ` [PATCH] reset: disallow --no-{mixed,soft,hard,merge,keep} René Scharfe
2023-07-21 12:41 ` [PATCH] pack-objects: fix --no-quiet René Scharfe
2023-07-21 12:41 ` [PATCH] pack-objects: fix --no-keep-true-parents René Scharfe
2023-07-21 17:03 ` Junio C Hamano
2023-07-21 12:42 ` [PATCH] branch: disallow --no-{all,remotes} René Scharfe
2023-07-21 12:42 ` [PATCH] am: unify definition of --keep-cr and --no-keep-cr René Scharfe
2023-07-21 13:41 ` [PATCH] describe: fix --no-exact-match René Scharfe
2023-07-21 14:10 ` Junio C Hamano
2023-07-21 17:00 ` Junio C Hamano
2023-08-08 21:27 ` Jeff King
2023-08-08 21:28 ` Jeff King
2023-08-09 1:43 ` Junio C Hamano
2023-08-09 14:09 ` Jeff King
2023-08-09 16:41 ` René Scharfe
2023-08-09 19:07 ` Junio C Hamano
2023-08-10 0:26 ` Jeff King
2023-08-10 1:00 ` Junio C Hamano
2023-08-10 19:45 ` René Scharfe
2023-08-10 0:41 ` Jeff King
2023-08-10 19:10 ` René Scharfe
2023-08-11 15:11 ` Jeff King
2023-08-11 17:59 ` René Scharfe
2023-08-11 18:24 ` Jeff King
2023-08-12 5:11 ` René Scharfe
2023-08-11 15:13 ` Jeff King
2023-08-11 17:59 ` René Scharfe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a19879db-d45a-ee42-1ad5-497e4e9eb8df@web.de \
--to=l.s.r@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).