From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Pierre Habouzit <madcoder@debian.org>, git@vger.kernel.org
Subject: Re: [PATCH] builtin-tag: fix fallouts from recent parsopt restriction.
Date: Mon, 17 Dec 2007 15:31:43 -0500 [thread overview]
Message-ID: <20071217203143.GA2105@coredump.intra.peff.net> (raw)
In-Reply-To: <7vy7bt6qv6.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 17, 2007 at 11:52:29AM -0800, Junio C Hamano wrote:
> So in short, for an option that takes optional option-argument:
I agree with everything you said, except...
> - 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.
This "plausible" makes me a little nervous, and I wonder why we want to
support this at all. Is it
1. We have traditionally supported "--abbrev 10"? I don't think this
is the case.
2. Consistency with "--non-optional-arg foo"? Do we have any such
non-optional long arguments? I didn't see any; I think we stick
with --non-optional-arg=foo everywhere.
3. More convenience to the user? I don't see how " " is easier than
"=".
> - 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.
Similarly, what is the goal here?
1. Have we ever supported "-s foo"? Not for -B/-M/-C, nor for
shortlog's -w.
2. This would add consistency to non-optional arguments.
3. It's longer to type.
So I see a slight case for "-s foo", but none at all for "--long foo".
-Peff
next prev parent reply other threads:[~2007-12-17 20:32 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
2007-12-17 20:31 ` Jeff King [this message]
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=20071217203143.GA2105@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=madcoder@debian.org \
/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).