git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Pierre Habouzit <madcoder@debian.org>
Cc: Jeff King <peff@peff.net>, git@vger.kernel.org
Subject: Re: [PATCH] builtin-tag: fix fallouts from recent parsopt restriction.
Date: Mon, 17 Dec 2007 11:52:29 -0800	[thread overview]
Message-ID: <7vy7bt6qv6.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: 20071217123307.GK7453@artemis.madism.org

Pierre Habouzit <madcoder@debian.org> writes:

> After having written this mail 4 time already, I came up with an idea I
> kind of like: like find, we could make {} be a placeholder for the
> "default" argument. For example:
>
>   $ git foo --abbrev {} 10
>   $ git log -M {} 1
>   ...
>
> {} would have the same semantics as your --long-opt-default. It tells the
> option parser that "no there isn't anything to grok for that command thank you
> very much". Of course if for some reason you really want to pass "{}" to the
> command, the stuck form holds:
>
>   $ git foo --long-opt={}
>   $ git foo -o{}
>
> What do you think ?

1. {} means a completely different thing to find ("place the real value
   here"); there is no similarity.  I would strongly oppose to it.  If
   you want to invoke opt with default but still want to pass "{}" as an
   argument unrelated to that opt, you would do "--opt={} {}".  That's
   double ugly.

2. For a long option with optional option-argument, --abbrev-default (or
   in the other order, --default-abbrev) to mark "there is no option
   argument, do not do your context sensitive parsing" and using an
   explicit '=' (e.g. --abbrev=<value>) to mark "this is the argument,
   do not do your context sensitive parsing" is much more readable.

3. There are only handful options with optional option-argument that
   does not have long format.  I think it is reasonable to require
   "stuck argument" to them.  For most of the short options that take
   optional option-argument, traditionally we did not allow them to be
   spelled as separate words, so there is no regression to introduce
   such a behaviour.  -B/-M/-C options to diff family would be handled
   sanely this way.

   Another possibility, which I do not like very much, is to add long
   format to them, if only for paranoid scripters who want rename
   detection with the default threshold and cannot say "diff -M $foo".
   They can say "diff --detect-rename-default $foo" instead ("-M" is a
   bad example here, as giving a single path never makes sense for -M so
   $foo cannot be a file whose name is e.g. "20", and default number of
   abbreviated commit object name is longer than 2 which means it would
   make it longer than "percentage" form of threshold).

So in short, for an option that takes optional option-argument:

   - if it is given as "--<long-name>-default", there is no optional
     argument, period.

   - if it is given as "--long-name" but there is no next word, there is
     no optional argument, either.

   - if it is given as "--long-name=value", that "value" is the
     argument.  Barf if it does not validate.

   - if it is given as "--long-name", and there is a next word, see if
     that is plausible as its argument.  Get it and signal the caller
     you consumed it, if it is.  Ignore it and signal the caller you
     didn't, if it isn't.

   - if it is given as "-svalue", that "value" is the argument.  Barf if
     it does not validate.

   - if it is given as "-s", and there is a next word, and if the option
     has long format counterpart as well, then see if the next word is
     plausible as its argument.  Get it and signal the caller you
     consumed it, if it is.  Ignore it and signal the caller you didn't,
     if it isn't.

   - if it is given as "-s" but the previous rule did not trigger, there
     is no optional argument.

  reply	other threads:[~2007-12-17 19:53 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-13  5:52 [RFH] convert shortlog to use parse_options Jeff King
2007-12-13  9:06 ` Pierre Habouzit
2007-12-13  9:10   ` Jeff King
2007-12-13  9:35     ` Pierre Habouzit
2007-12-13 10:26       ` [PATCH 1/2] parseopt: Enforce the use of the sticked form for optional arguments Pierre Habouzit
2007-12-13 10:27         ` [PATCH 2/2] parseopt: Add a gitcli(5) man page Pierre Habouzit
2007-12-13 11:04           ` Wincent Colaiuta
2007-12-13 13:56             ` Pierre Habouzit
2007-12-17  7:28           ` [PATCH] (squashme) gitcli documentation fixups Junio C Hamano
2007-12-17  8:51             ` Pierre Habouzit
2007-12-17  8:57             ` Pierre Habouzit
2007-12-17  7:28         ` [PATCH] builtin-tag: fix fallouts from recent parsopt restriction Junio C Hamano
2007-12-17  9:07           ` Pierre Habouzit
2007-12-17 10:53             ` Junio C Hamano
2007-12-17 10:58               ` Pierre Habouzit
2007-12-17 11:21                 ` Junio C Hamano
2007-12-17 12:33                   ` Pierre Habouzit
2007-12-17 19:52                     ` Junio C Hamano [this message]
2007-12-17 20:31                       ` Jeff King
2007-12-17 20:42                         ` Pierre Habouzit
2007-12-17 21:01                           ` Pierre Habouzit
2007-12-17 23:07                             ` Jeff King
2007-12-17 23:14                               ` Pierre Habouzit
2007-12-17 20:42                         ` Junio C Hamano
2007-12-17 20:53                           ` Jeff King
2007-12-17 21:24                             ` Pierre Habouzit
2007-12-17 21:11                       ` Pierre Habouzit
2007-12-17 11:13             ` Junio C Hamano
2007-12-17 11:56               ` Pierre Habouzit
2007-12-17 11:59                 ` Pierre Habouzit
2007-12-13 17:40       ` [RFH] convert shortlog to use parse_options Junio C Hamano
2007-12-13 18:03         ` Pierre Habouzit
2007-12-13 18:07           ` Pierre Habouzit
2007-12-13 19:49             ` Junio C Hamano
2007-12-13 18:28           ` Kristian Høgsberg
2007-12-13 18:47             ` Kristian Høgsberg
2007-12-13 20:46               ` Junio C Hamano
2007-12-14  4:08               ` Jeff King
2007-12-14  5:59                 ` Junio C Hamano
2007-12-14  8:33                   ` Andreas Ericsson
2007-12-14  8:39                   ` Pierre Habouzit
2007-12-14 20:34                     ` Junio C Hamano
2007-12-15 11:03                       ` Pierre Habouzit
2007-12-17  7:27                         ` Junio C Hamano
2007-12-17  7:36                           ` Andreas Ericsson
2007-12-17  7:59                             ` Junio C Hamano
2007-12-17  9:38                               ` Andreas Ericsson
2007-12-17 16:21                               ` Kristian Høgsberg
2007-12-13 19:31           ` Junio C Hamano
2007-12-13 20:53             ` Pierre Habouzit
2007-12-13  9:29   ` Pierre Habouzit

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=7vy7bt6qv6.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=madcoder@debian.org \
    --cc=peff@peff.net \
    /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).