git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Kristian Høgsberg" <krh@redhat.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Andreas Ericsson <ae@op5.se>,
	Pierre Habouzit <madcoder@debian.org>, Jeff King <peff@peff.net>,
	git@vger.kernel.org
Subject: Re: [RFH] convert shortlog to use parse_options
Date: Mon, 17 Dec 2007 11:21:03 -0500	[thread overview]
Message-ID: <1197908463.8463.9.camel@hinata.boston.redhat.com> (raw)
In-Reply-To: <7v3au1eopr.fsf@gitster.siamese.dyndns.org>

On Sun, 2007-12-16 at 23:59 -0800, Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
> 
> > Junio C Hamano wrote:
> > 
> >> ...  The
> >> "must stick" restriction feels Ok on paper but in practice it looks
> >> rather draconian and very user unfriendly.
> >
> > Usually, optional arguments warrant adding a second parameter. This can
> > often even improve usability, as it's never unclear or ambiguous what's
> > happening. For the 'git tag -l' case, I'd use something like
> > 'git tag -l --match="regex"' or some such,...
> 
> That is essentially arguing for POSIXly correct "do not allow optional
> option-arguments" (utility syntax guidelines #7).  That position might
> be politically correct, but I am already discussing beyond that:
> usability.
> 
> For "git tag -l", the fix was rather simple, as the option would either
> have taken a zero pattern (list all) or a single pattern (list matching
> this pattern), and the command itself did not take any extra arguments,
> so that was what I did in the patch.  Compare your POSIXly correct
> version:
> 
>         git tag -l			(ok)
>         git tag -l pattern		(not ok)
> 	git tag -l --match=pattern	(ok)
> 
> with the traditional (and fixed):
> 
>         git tag -l			(ok)
>         git tag -l pattern		(ok)
> 	git tag -l pattern garbage	(not ok)
> 
> Which one is easier for the user?

git tag now lists tags by default so there's a couple of other options
to consider:

        git tag				(ok)
        git tag --match pattern		(ok)
	git tag --match=pattern     	(ok)
	git tag --match=pattern -l	(ok)
	git tag -l pattern		(not ok)

Or we could repurpose -l as the match option:

	git tag			(ok)
	git tag -l		(not ok)
	git tag -l pattern	(ok)

And that was the point I was trying to make earlier with my rather
abstract sounding post about jumping through hoops.  If we can't break
the options interface to make git sane, we'll be stuck with a broken
command line interface and must write complicated documents on what option
sticking is and how it works.

cheers,
Kristian

  parent reply	other threads:[~2007-12-17 16:23 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
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 [this message]
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=1197908463.8463.9.camel@hinata.boston.redhat.com \
    --to=krh@redhat.com \
    --cc=ae@op5.se \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=madcoder@debian.org \
    --cc=peff@peff.net \
    /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).