All of lore.kernel.org
 help / color / mirror / Atom feed
From: "SZEDER Gábor" <szeder@ira.uka.de>
To: Stephen Boyd <bebarino@gmail.com>
Cc: git@vger.kernel.org, spearce@spearce.org,
	felipe.contreras@gmail.com, jrnieder@gmail.com
Subject: Re: [PATCH 1/2] parse-options: Add support for dumping out long options
Date: Sun, 15 Apr 2012 14:49:19 +0200	[thread overview]
Message-ID: <20120415124919.GD2900@goldbirke> (raw)
In-Reply-To: <4F868060.1000709@gmail.com>

Hi,


On Thu, Apr 12, 2012 at 12:12:32AM -0700, Stephen Boyd wrote:
> On 04/11/2012 07:06 AM, SZEDER Gábor wrote:
> > On Wed, Apr 11, 2012 at 03:29:24AM -0700, Stephen Boyd wrote:
> >> The bash completion script wants to know what the long options are for a
> >> certain command at runtime. Add a magical long option that nobody could
> >> possibly ever use (--dump-raw-long-options) to get this information.
> >>
> >> Some example output:
> >>
> >>  $ git clone --dump-raw-long-options
> >>  --no-verbose --no-quiet --progress --no-progress --no-checkout
> >>  --checkout --bare --no-bare --mirror --no-mirror --local --no-local
> >>  --no-hardlinks --hardlinks --shared --no-shared --recursive
> >>  --no-recursive --recurse-submodules --no-recurse-submodules --template=
> >>  --no-template --reference= --no-reference --origin= --no-origin
> >>  --branch= --no-branch --upload-pack= --no-upload-pack --depth=
> >>  --no-depth --single-branch --no-single-branch --separate-git-dir=
> >>  --no-separate-git-dir --config= --no-config
> >>
> > 
> > I think this is a good idea; there are many completion functions that
> > fell behind and lack an option or two.
> > 
> > However, in the completion script we deliberately miss options like
> > '--force', but with your series such options will be offered, too.
> > 
> 
> Hm.. I meant to say something about that in the commit text. I'm willing
> to live with wading through some more options when I tab complete if it
> means the script never falls out of date with my git installation.
> 
> I can envision us putting more smarts into the parse options code to
> hide certain options from the raw dump but I'm not sure how useful that
> is. Do we need that?

It's not just about wading through some more options.

Parse options already has the PARSE_OPT_HIDDEN flag to omit an option
from the default usage.  Your patch already respects that option, so
e.g. 'git commit --<TAB>' won't offer '--allow-empty', which is meant
for foreign SCM interface scripts.  This is good.

However, '--force' is different, because it should be shown in the
default usage, but since it's a "dangerous" option it should be use
with great care.  That's the reason the completion script doesn't
offer it for any of the commands.

I'm not sure whether there are any such options besides '--force',
though.  If that is the only one, then maybe this is all we need:


diff --git a/parse-options.c b/parse-options.c
index 6c37497c..1a2b0328 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -371,6 +371,8 @@ static int parse_options_raw(const struct option *opts)
 			continue;
 		if (!opts->long_name)
 			continue;
+		if (!strcmp(opts->long_name, "force"))
+			continue;
 		switch (opts->type) {
 		case OPTION_BIT:
 		case OPTION_NEGBIT:


Best,
Gábor

  reply	other threads:[~2012-04-15 12:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-11 10:29 [PATCH 0/2] Dynamic long options for bash completion Stephen Boyd
2012-04-11 10:29 ` [PATCH 1/2] parse-options: Add support for dumping out long options Stephen Boyd
2012-04-11 10:51   ` Felipe Contreras
2012-04-12  7:42     ` Stephen Boyd
2012-04-11 12:59   ` Jonathan Nieder
2012-04-12  7:02     ` Stephen Boyd
2012-04-11 14:06   ` SZEDER Gábor
2012-04-12  7:12     ` Stephen Boyd
2012-04-15 12:49       ` SZEDER Gábor [this message]
2012-04-15 19:23         ` Junio C Hamano
2012-04-11 10:29 ` [PATCH 2/2] completion: Use parse-options raw output for simple " Stephen Boyd
2012-04-11 13:09   ` Jonathan Nieder
2012-04-11 13:56   ` SZEDER Gábor
2012-04-17 10:44   ` SZEDER Gábor

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=20120415124919.GD2900@goldbirke \
    --to=szeder@ira.uka.de \
    --cc=bebarino@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=spearce@spearce.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 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.