On Thu, Dec 13, 2007 at 01:47:36PM -0500, Kristian Høgsberg wrote: > 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. I agree. I am already a little bit uncomfortable with the "--abbrev 10" won't work but "--foo 10" will, because it requires that the user remember which arguments are optional and which are required. But switching it to "--abbrev 10 works, but --abbrev $foo does not, unless of course $foo is an integer, in which case you must use --abbrev=$foo" is just a little bit too DWIM. E.g., if you are scripting, it's just one more source of error (if I have $foo, how must I write --abbrev $foo for it to ensure that I _don't_ trigger the optional argument?). -Peff - 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
