Re: [RFH] convert shortlog to use parse_options

From: Kristian Høgsberg <krh@redhat.com>
Date: Dec 17, 2007, 16:21 UTC
Message-ID: <1197908463.8463.9.camel@hinata.boston.redhat.com>
In-Reply-To: <7v3au1eopr.fsf@gitster.siamese.dyndns.org>

On Sun, 2007-12-16 at 23:59 -0800, Junio C Hamano wrote:

Show 35 quoted lines

> 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