All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Pierre Habouzit <madcoder@debian.org>
Cc: Jeff King <peff@peff.net>, Shawn Bohrer <shawn.bohrer@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH 1/2] parse_options: Add flag to prevent errors for  further processing
Date: Sun, 22 Jun 2008 18:45:11 -0700	[thread overview]
Message-ID: <7vod5skjq0.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <20080622170733.GA16252@artemis.madism.org> (Pierre Habouzit's message of "Sun, 22 Jun 2008 19:07:33 +0200")

Pierre Habouzit <madcoder@debian.org> writes:

> On Wed, Jun 18, 2008 at 05:13:02AM +0000, 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.
>
> If you do that, you need to relocate pars option structures,...
> ... Note that "recursing"
> is not really trivial, because with flags aggregation and stuff like
> that, things that look like an option can also be a value in the context
> of an other option parser.

Note that I was just saying "not necessarily" in response to "the only
right way" to point out it is not the _only_ way.

Parse-options has been done in a tablish way and it would involve cost to
modify it in a way I outlined (even if such a rewrite would make chaining
different set of option parsers easier, as each parser needs to handle
only what it knows about and handling aggregation and stuff would become
trivial).  I do not know if it is worth the cost, and I am not married to
the option parser structure that diff and revision part uses.

      reply	other threads:[~2008-06-23  1:46 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
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 [this message]

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=7vod5skjq0.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --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.