On Thu, 2007-12-13 at 13:28 -0500, Kristian Høgsberg wrote: > 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 Oops, sorry about that. I just wanted to say we shouldn't jump through all these hoops to make the option parser support every type of option there ever was in the git command line ui. A lot of these were probably decided somewhat arbitrarily by whoever implemented the command. Instead it's an opportunity to retroactively enforce some consistency and predictability to the various option-styles that have been hand-rolled over time in different git commands. 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
