All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Jeff King <peff@peff.net>, Shawn Bohrer <shawn.bohrer@gmail.com>,
	git@vger.kernel.org, madcoder@debian.org
Subject: Re: [PATCH 1/2] parse_options: Add flag to prevent errors for further processing
Date: Wed, 18 Jun 2008 11:52:42 -0700	[thread overview]
Message-ID: <7v8wx2zibp.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <alpine.DEB.1.00.0806181709300.6439@racer> (Johannes Schindelin's message of "Wed, 18 Jun 2008 17:50:31 +0100 (BST)")

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Tue, 17 Jun 2008, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>> 
>> > I think the only right way to accomplish this is to convert the revision
>> > and diff parameters into a parseopt-understandable format.
>> 
>> Not necessarily.  You could structure individual option parsers like how 
>> diff option parsers are done.  You iterate over argv[], feed diff option 
>> parser the current index into argv[] and ask if it is an option diff 
>> understands, have diff eat the option (and possibly its parameter) to 
>> advance the index, or allow diff option to say "I do not understand 
>> this", and then handle it yourself or hand it to other parsers.
>
> AFAIR Pierre tried a few ways, and settled with a macro to introduce the 
> diff options into a caller's options.
>
> IOW it would look something like this:
>
> static struct option builtin_what_options[] = {
> 	[... options specific to this command ...]
> 	DIFF__OPT(&diff_options)
> };

I think that is the more painful approach Jeff mentioned, and my comment
was to show that it is not the only way.

  reply	other threads:[~2008-06-18 18:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-18  3:03 [RFC] convert shortlog to use parse_options Shawn Bohrer
2008-06-18  3:03 ` [PATCH 1/2] parse_options: Add flag to prevent errors for further processing Shawn Bohrer
2008-06-18  3:03   ` [PATCH 2/2] git shortlog: Modify to use parse_options Shawn Bohrer
2008-06-18  3:21   ` [PATCH 1/2] parse_options: Add flag to prevent errors for further processing Junio C Hamano
2008-06-18  3:30     ` Jeff King
2008-06-18  3:34       ` Jeff King
2008-06-18  5:13       ` Junio C Hamano
2008-06-18 16:50         ` Johannes Schindelin
2008-06-18 18:52           ` Junio C Hamano [this message]
2008-06-19 14:25             ` Shawn Bohrer
2008-06-22 19:07               ` Johannes Schindelin
2008-06-23 19:55                 ` Junio C Hamano
2008-06-23 19:59                   ` Jeff King
2008-06-23 20:17                     ` Junio C Hamano
2008-06-23 20:24                   ` Johannes Schindelin
2008-06-22 17:07         ` Pierre Habouzit
2008-06-23  1:45           ` Junio C Hamano

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=7v8wx2zibp.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=madcoder@debian.org \
    --cc=peff@peff.net \
    --cc=shawn.bohrer@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.