git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Nicolas Vigier <boklm@mars-attacks.org>
Cc: Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org, Pierre Habouzit <madcoder@debian.org>
Subject: Re: [PATCH] rev-parse --parseopt: fix handling of optional arguments
Date: Wed, 16 Oct 2013 15:33:06 -0700	[thread overview]
Message-ID: <20131016223306.GN9464@google.com> (raw)
In-Reply-To: <20131016141411.GB4589@mars-attacks.org>

Nicolas Vigier wrote:

> I'm thinking about a patch to add the following two options to rev-parse :
>
> --sticked-opt-args::
> 	Only meaningful in --parseopt mode. Tells the options parser to
> 	output options with optional arguments in sticked form. The
> 	default is to output them in non-sticked mode, which can be
> 	difficult to parse unambiguously.
>
> --long-options::
> 	Only meaningful in --parseopt mode. Tells the options parser to
> 	output long option names, when available. The default is to use
> 	short option names when available.
>
> When you want to handle optional args unambiguously, you use the
> --sticked-opt-args option. And if you think an empty value can be
> a meaningful value, you add the --long-options option to be able to
> distinguish them.
>
> Would it make sense ?

That would make four distinct output formats:

 --sticked --long:
	Doesn't lose any information that normal use of C parse_options
	would have kept, as long as every short option with optional
	argument has a corresponding long option.


 --sticked --no-long:
	Loses the distinction between --gpg-sign and --gpg-sign=

 --no-sticked --long:
	Semantically equivalent to the existing output, just noisier.

 --no-sticked --no-long:
 	The existing output.

Are all of them needed?  Is it worth tempting people to use --sticked
--no-long when we know its pitfalls?

I would think that only the current normalized form and --sticked
--long would need to be supported.

The fix you originally proposed seems tolerable to me, too --- it is
not very invasive, and while it doesn't distinguish the empty-argument
form "--gpg-sign=", that's a bit of an edge case.

The main reason I slightly prefer the solution that makes the output
use long, sticked options on request is that the "normalized"
commandline would start being an actual equivalent command line the
command expects, instead of a weird, subtly different syntax.  (That
problem already exists with or without your patch --- the patch just
draws attention to it.)

  reply	other threads:[~2013-10-16 22:33 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-15 12:00 [PATCH] rev-parse --parseopt: fix handling of optional arguments Nicolas Vigier
2013-10-15 22:55 ` Junio C Hamano
2013-10-15 23:47   ` Nicolas Vigier
2013-10-15 23:14 ` Jonathan Nieder
2013-10-15 23:33   ` Junio C Hamano
2013-10-15 23:57     ` Jonathan Nieder
2013-10-16  7:04       ` Johannes Sixt
2013-10-16  8:53         ` Jeff King
2013-10-16 21:40           ` Junio C Hamano
2013-10-16 21:50             ` Jeff King
2013-10-16 10:58         ` Nicolas Vigier
2013-10-16 14:14       ` Nicolas Vigier
2013-10-16 22:33         ` Jonathan Nieder [this message]
2013-10-25 20:18           ` [PATCH] rev-parse --parseopt: add the --sticked-long mode Nicolas Vigier
2013-10-25 22:01             ` Junio C Hamano
2013-10-25 22:52               ` Nicolas Vigier
2013-10-25 22:55                 ` Junio C Hamano
2013-10-26 21:55                   ` Philip Oakley
2013-10-28 15:47                     ` Junio C Hamano
2013-10-31 11:08               ` sticked -> stuck Nicolas Vigier
2013-10-31 11:08                 ` [PATCH 1/2] Use the word 'stuck' instead of 'sticked' Nicolas Vigier
2013-10-31 19:35                   ` Junio C Hamano
2013-10-31 11:08                 ` [PATCH 2/2] rev-parse --parseopt: add the --stuck-long mode Nicolas Vigier
2013-10-27  5:45             ` [PATCH] rev-parse --parseopt: add the --sticked-long mode Michael Haggerty
2013-10-15 23:53   ` [PATCH] rev-parse --parseopt: fix handling of optional arguments Nicolas Vigier

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=20131016223306.GN9464@google.com \
    --to=jrnieder@gmail.com \
    --cc=boklm@mars-attacks.org \
    --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).