From: Jeff King <peff@peff.net>
To: Clemens Buchacher <drizzd@aon.at>
Cc: "Shawn O. Pearce" <spearce@spearce.org>, git@vger.kernel.org
Subject: Re: [PATCH 1/2] do not mangle short options which take arguments
Date: Fri, 2 Oct 2009 02:11:59 -0400 [thread overview]
Message-ID: <20091002061159.GA24892@coredump.intra.peff.net> (raw)
In-Reply-To: <20091001201648.GA12175@localhost>
On Thu, Oct 01, 2009 at 10:16:48PM +0200, Clemens Buchacher wrote:
> Instead of
>
> $ git commit -a -ammend
> [work ce38944] mend
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> we now get
>
> $ git commit -a -ammend
> error: switch `m' must not be mangled with other options
> usage: git commit [options] [--] <filepattern>...
> [...]
>
> Signed-off-by: Clemens Buchacher <drizzd@aon.at>
> ---
> On Fri, Sep 25, 2009 at 04:32:26PM -0700, Shawn O. Pearce wrote:
> > I wonder, should the -m flag on commit not allow cuddling its
> > value against the switch when its combined in short form with
> > other switches?
>
> Here we go.
I thought the proposal was to disallow just cuddling of the value when
the switch was combined with others. So you would disallow "git commit
-ammend" but it would still be legal to do "git commit -am foo". Your
patch disallows the latter.
I would prefer to allow the uncuddled form, as it is something I do
occasionally (and I don't think "git commit -am foo" looks very much
like a typo).
To be honest, I am not sure that even the more restricted proposal is
that good an idea. You are introducing a heuristic to guess at what is a
typo or error from the user; when your guess is wrong, the user will be
annoyed (doubly so if it is buried deep in a script, which this change
will also impact). So you are guessing that people don't use the
cuddled form in this way. I suspect most don't. But I also wonder how
many typos you are really helping to save. This was brought up to make
"-ammend" DWYM. Is that really that common a double-typo?
On the other hand, the cuddled value already has some DWYM magic (it
recognizes -amend), so it is already a little bit unsafe to use
(interestingly, though, the gitcli(7) documentation actually recommends
using the "sticked" form over the separated one. However, it also
recommends splitting your short options).
So I don't feel _too_ strongly. I am just concerned that we are
introducing some DWYM magic that is not really going to help many people
out, and is just going to make understanding the rules for option
parsing more complex, and introduce the possibility (albeit slim) of
breaking people's scripts and trained fingers.
-Peff
next prev parent reply other threads:[~2009-10-02 6:12 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-25 23:32 how optparse can go horribly wrong Shawn O. Pearce
2009-09-26 1:51 ` Nicolas Sebrecht
2009-09-26 13:44 ` Sverre Rabbelier
2009-09-26 19:25 ` Shawn O. Pearce
2009-09-28 13:37 ` Clemens Buchacher
2009-10-01 20:16 ` [PATCH 1/2] do not mangle short options which take arguments Clemens Buchacher
2009-10-01 20:23 ` [PATCH 2/2] allow mangling short options which take integer arguments Clemens Buchacher
2009-10-01 21:55 ` Johannes Schindelin
2009-10-02 7:43 ` Clemens Buchacher
2009-10-02 7:50 ` Jeff King
2009-10-02 8:26 ` Clemens Buchacher
2009-10-02 8:41 ` Johannes Schindelin
2009-10-03 9:23 ` Clemens Buchacher
2009-10-01 21:53 ` [PATCH 1/2] do not mangle short options which take arguments Johannes Schindelin
2009-10-02 6:11 ` Jeff King [this message]
2009-10-02 7:36 ` Clemens Buchacher
2009-10-02 7:46 ` Paolo Bonzini
2009-10-02 7:57 ` Jeff King
2009-10-02 8:42 ` Johannes Schindelin
2009-10-02 8:43 ` Jeff King
2009-10-02 9:04 ` Johannes Schindelin
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=20091002061159.GA24892@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=drizzd@aon.at \
--cc=git@vger.kernel.org \
--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 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).