From: Pierre Habouzit <madcoder@debian.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH PARSEOPT 1/4] parse-options new features.
Date: Fri, 09 Nov 2007 01:17:19 +0100 [thread overview]
Message-ID: <20071109001719.GA22255@artemis.corp> (raw)
In-Reply-To: <7vbqa4z3ts.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1271 bytes --]
On Thu, Nov 08, 2007 at 11:59:27PM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > options flags:
> > ~~~~~~~~~~~~~
> > PARSE_OPT_NONEG allow the caller to disallow the negated option to exists.
>
> Good addition; writing OPT_CALLBACK was tricky without this when
> I tried to add --with=<commit> to git-branch.
Well, you could do the same by hand, in the callback:
if (unset)
return error("go away with your --no-%s", opt->long_name);
This is correct because only long options can be negated, and if the
callback returns -1 (< 0 actually IIRC, or maybe even !0) then
parse_options assume that you dealt with the error message, and will
just print out the usage and exit(129).
So it merely offloads something that you could already do the very
same way _when using a callback_.
It gets more interesting when you want to use an
OPT_INT/_STRING/whatever with an argument that isn't a callback and
don't want for some reason that --no-foo works. Before that change, you
needed a callback, now you don't :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-11-09 1:12 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-07 10:20 Preliminary patches to the diff.[hc] parseoptification Pierre Habouzit
2007-11-07 10:20 ` [PATCH MISC 1/1] Make gcc warning about empty if body go away Pierre Habouzit
2007-11-07 10:20 ` [PATCH PARSEOPT 1/4] parse-options new features Pierre Habouzit
2007-11-07 10:20 ` [PATCH PARSEOPT 2/4] Use OPT_SET_INT and OPT_BIT in builtin-branch Pierre Habouzit
2007-11-07 10:20 ` [PATCH PARSEOPT 3/4] Use OPT_BIT in builtin-for-each-ref Pierre Habouzit
2007-11-07 10:20 ` [PATCH PARSEOPT 4/4] Use OPT_BIT in builtin-pack-refs Pierre Habouzit
2007-11-07 10:20 ` [PATCH DIFF-CLEANUP 1/2] Make the diff_options bitfields be an unsigned with explicit masks Pierre Habouzit
2007-11-07 10:20 ` [PATCH DIFF-CLEANUP 2/2] Reorder diff_opt_parse options more logically per topics Pierre Habouzit
2007-11-08 6:39 ` [PATCH DIFF-CLEANUP 1/2] Make the diff_options bitfields be an unsigned with explicit masks Junio C Hamano
2007-11-08 8:17 ` Pierre Habouzit
2007-11-10 19:05 ` [UPDATE " Pierre Habouzit
2007-11-08 23:59 ` [PATCH PARSEOPT 1/4] parse-options new features Junio C Hamano
2007-11-09 0:17 ` Pierre Habouzit [this message]
2007-11-08 1:52 ` [PATCH MISC 1/1] Make gcc warning about empty if body go away Junio C Hamano
2007-11-08 2:01 ` Junio C Hamano
2007-11-08 8:12 ` Pierre Habouzit
2007-11-08 8:41 ` Andreas Ericsson
2007-11-08 15:20 ` Jon Loeliger
2007-11-08 15:47 ` Andreas Ericsson
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=20071109001719.GA22255@artemis.corp \
--to=madcoder@debian.org \
--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 NNTP newsgroup(s).