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

[Eric Wong <normalperson@yhbt.net>]

Timo Hirvonen <tihirvon@gmail.com> wrote:
> 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).

> >  * 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