On Thu, Dec 13, 2007 at 06:03:47PM +0000, Pierre Habouzit wrote: > On Thu, Dec 13, 2007 at 05:40:23PM +0000, Junio C Hamano wrote: > > Pierre Habouzit <madcoder@xxxxxxxxxx> writes: > > > > > In fact we have kind of the issue for every single optional argument out > > > there: > > > > > > $ git describe --abbrev HEAD > > > error: option `abbrev' expects a numerical value > > > [...] > > > > > > *ouch* > > > > > > So I believe that with optional arguments we must change the way we do > > > things, and that we _must_ enforce the argument to be sticked in that > > > case. > > > > I think "Must" is a bit too strong an expression. > > > > git describe --abbrev 7 HEAD > > git describe --abbrev HEAD > > git describe --abbrev=HEAD > > git describe --abbrev=7 HEAD > > git describe --abbrev > > > > The --abbrev parser in this case could be asked with this question: "You > > are on the command line. There is a token after you. Is it your > > parameter?". The other issue is that when you had --abbrev=foo or --abbrev foo, the first one has to generate an error, whereas the second one should just say "foo" is not for me. The point being that the callback is not really aware of how the argument got assigned to it. That means that we will have to pass more flags to callabacks, making it less easy to write them. Again, I'm not sure that the coding hassle is worth of the small gain. -- ·O· Pierre Habouzit ··O madcoder@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgpiFCuVD9Qpe.pgp
Description: PGP signature
