Re: [PATCH 1/6] gitopt: a new command-line option parser for git

From: Eric Wong <normalperson@yhbt.net>
Date: May 9, 2006, 19:18 UTC
Message-ID: <20060509191803.GA3676@localdomain>
In-Reply-To: <20060509120809.4d9494b9.tihirvon@gmail.com>

Timo Hirvonen <tihirvon@gmail.com> wrote:

Show 7 quoted lines

> 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"?

It is more for me. Many programs that I use already accept bundled switches, and '=' and '-' are relatively far away and requires me to stretch my hand uncomfortably (I have very small hands, and have limited mobility in several fingers).

Show 14 quoted lines

> >  * optional argument handling (-C<num>, -M<num>)
> >    -C <num> (with a space between them) has not changed,
> >    however, <num> can be a sha1, or a path
> 
> IMO optional arguments are usually bad idea.
> 
>     -C 2 (is "2" argument?)
>     -C2  (-C=2 or -C -2?)
> 
> Better to make it obvious there's an argument
> 
>     -C=2
> 
> or not support optional arguments at all and "-C 2" becomes unambiguous.

git has always supported optional argument handling like this.

I'm striving for backwards compatibility with existing usage. That means as a diff option, -C alone works, as does -C20. I've made -C 20 _not_ work because it breaks existing usage (where 20 could be a filename, or a tree-ish). -C=20 would mean something else, since I wanted to make pickaxe work exactly as it did before: -S=var would search for '=var', not 'var'.

-- 
Eric Wong