From: Junio C Hamano <junkio@cox.net>
To: Timo Hirvonen <tihirvon@gmail.com>, Eric Wong <normalperson@yhbt.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/6] gitopt: a new command-line option parser for git
Date: Tue, 09 May 2006 05:58:45 -0700 [thread overview]
Message-ID: <7v8xpb73sq.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <20060509120809.4d9494b9.tihirvon@gmail.com> (Timo Hirvonen's message of "Tue, 9 May 2006 12:08:09 +0300")
Timo Hirvonen <tihirvon@gmail.com> writes:
> Eric Wong <normalperson@yhbt.net> wrote:
>
>> * unbundling of short options: -uC20n20z => -u -C20 -n20 -z
>
> Does anyone ever use this? I think this makes sense only for flags that
> don't have parameters but that would create an ugly special case. Is it
> too hard to type "-u -C=20 -n=20 -z"?
I can already hear in my head that people would start talking
about "git understands insane abbeviations of options". It
might be unambiguous, but that does not change it is a bit on
the insane side. People would probably expect -nuz can be split
into -n -u -z, and the current handcrafted mess (although it is
more obvious and easy to work with when reading and maintaining
the existing code) is not abbreviation friendly, which we would
want to do something about. But I think squashing options with
parameters together is going a bit too far.
> --with-r => --patch-with-raw works great
I personally think this also is too much.
next prev parent reply other threads:[~2006-05-09 12:58 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-09 5:06 [PATCH/RFC] gitopt - command-line parsing enhancements Eric Wong
2006-05-09 5:06 ` [PATCH 1/6] gitopt: a new command-line option parser for git Eric Wong
2006-05-09 5:06 ` [PATCH 2/6] update-index: convert to using gitopt Eric Wong
2006-05-09 5:06 ` [PATCH 3/6] ls-tree: convert to gitopt Eric Wong
2006-05-09 5:06 ` [PATCH 4/6] ls-files: convert to using gitopt Eric Wong
2006-05-09 5:06 ` [PATCH 5/6] gitopt: convert setup_revisions(), and diff_opt_parse() Eric Wong
2006-05-09 5:06 ` [PATCH 6/6] commit: allow --pretty= args to be abbreviated Eric Wong
2006-05-09 7:16 ` [PATCH 5/6] gitopt: convert setup_revisions(), and diff_opt_parse() Eric Wong
2006-05-11 20:19 ` Eric Wong
2006-05-09 9:08 ` [PATCH 1/6] gitopt: a new command-line option parser for git Timo Hirvonen
2006-05-09 12:58 ` Junio C Hamano [this message]
2006-05-09 19:39 ` Eric Wong
2006-05-09 19:18 ` Eric Wong
2006-05-09 20:10 ` Timo Hirvonen
2006-05-09 20:35 ` Junio C Hamano
2006-05-09 21:08 ` Timo Hirvonen
2006-05-09 21:11 ` Junio C Hamano
2006-05-09 21:31 ` Timo Hirvonen
2006-05-09 8:35 ` [PATCH/RFC] gitopt - command-line parsing enhancements Junio C Hamano
2006-05-09 19:48 ` Eric Wong
2006-05-09 20:28 ` Junio C Hamano
2006-05-09 21:14 ` Eric Wong
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=7v8xpb73sq.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=git@vger.kernel.org \
--cc=normalperson@yhbt.net \
--cc=tihirvon@gmail.com \
/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).