git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pierre Habouzit <madcoder@debian.org>
To: Carlos Rica <jasampler@gmail.com>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	git@vger.kernel.org, "Kristian Høgsberg" <krh@redhat.com>
Subject: Re: [PATCH] Make builtin-tag.c use parse_options.
Date: Mon, 12 Nov 2007 15:52:52 +0100	[thread overview]
Message-ID: <20071112145252.GA343@artemis.corp> (raw)
In-Reply-To: <1b46aba20711120509l104792ebo4ea9a51c710510f3@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]

On Mon, Nov 12, 2007 at 01:09:37PM +0000, Carlos Rica wrote:
> 2007/11/10, Junio C Hamano <gitster@pobox.com>:
> > Carlos Rica <jasampler@gmail.com> writes:
> >
> > > Also, this removes those tests ensuring that repeated
> > > -m options don't allocate memory more than once, because now
> > > this is done after parsing options, using the last one
> > > when more are given. The same for -F.
> >
> > The reason for this change is...?  Is this because it is
> > cumbersome to detect and refuse multiple -m options using the
> > parseopt API?  If so, the API may be what needs to be fixed.
> > Taking the last one and discarding earlier ones feels to me an
> > arbitrary choice.
> 
> You can do many things with repeated options.
> Here in git-tag we considered two different ways to manage them:
> Concatenating values for the option and/or refusing more than one.
> I found that current option-parser can do both from the client
> using callbacks, as Pierre shows me, so I think it is the right way to do it.
> 
> Pierre, by default, I think that the parser should print an error
> when more than one option of the same type is given,

  I beg to differ. It makes sense for OPTION_STRING options, but not for
other. Though you cannot always detect that.

Also note that:
(1) repeating options was already silent in many git commands, so it's
    not really a regression ;
(2) for many commands it actually make sense to allow repeating (for
    _BOOLEAN e.g.). And I'd argue that for OPTION_BIT it also makes
    sense as well.

> in order to report it to the command-line user, but make this
> behaviour optional for the programmer.  Specifically, I thought in
> this last option:
> 
> enum parse_opt_option_flags {
> 	PARSE_OPT_OPTARG   = 1,
> 	PARSE_OPT_NOARG    = 2,
> 	PARSE_OPT_ALLOWREP = 4
> };

  To do that you need to keep a list of the triggered commands to do
that, there is no way to achieve that reliably right now. As taking the
last one and discarding the other is the usual way for option parsers I
never saw this as a big issue.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-11-12 14:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-09 13:42 [PATCH] Make builtin-tag.c use parse_options Carlos Rica
2007-11-09 13:57 ` Jakub Narebski
2007-11-09 14:31   ` Johannes Schindelin
2007-11-10  6:07 ` Junio C Hamano
2007-11-10  9:26   ` Junio C Hamano
2007-11-10  9:41     ` Junio C Hamano
2007-11-10 12:25   ` Carlos Rica
2007-11-10 13:13     ` Pierre Habouzit
2007-11-12 13:09   ` Carlos Rica
2007-11-12 14:52     ` Pierre Habouzit [this message]
2007-11-12 19:48     ` Kristian Høgsberg

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=20071112145252.GA343@artemis.corp \
    --to=madcoder@debian.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jasampler@gmail.com \
    --cc=krh@redhat.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).