On Sun, 2007-12-16 at 23:59 -0800, Junio C Hamano wrote:
> Andreas Ericsson <ae@xxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
