On Thu, 2007-12-13 at 19:03 +0100, 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?". > > I thought of that, but it's really convoluted and can definitely lead > to very subtle issues. The number of git commands with optional > arguments is quite low, mostly due to legacy, I don't expect _new_ > commands to take optional arguments. I don't really like the ambiguity > it creates, and in some cases you just won't be able to disambiguate at > all. Here it looks nice because --abbrev takes an integer argument, and > it's likely that no branch nor reference names will be only made of > digits. Though for commands taking an optional string[0] argument this is > way more fishy. My - 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
