Jeff King <peff@xxxxxxxx> writes: > 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?). Oh, there is no question that scripted callers need a way to safely disambiguate, and be able to call "git cmd" with always the default abbreviation for whatever $foo it gets from the user unambiguously. I do not disagree with that. But that is different from making it harder for end users (not scripters but command line users). Again, I am not saying that my suggested alternative is superiour; I just threw it out to as an example of a different approach to achieve disambiguation than the "some flags must have its parameter stuck with it, some don't" behaviour, which will surely be confusing to the command line end users. To contrast the two, with Pierre's, if you want $n-digit abbreviations and $cnt-lines of output in your script, your script would say: git cmd --abbrev=$n -n $cnt $foo because you as a script writer are required to know --abbrev is such a magic flag that take optional parameter and cannot be fed as two options (you can also write "-n=$cnt", but I am talking about --abbrev part). If you are accepting the default abbreviation, on the other hand: git cmd --abbrev -n $cnt $foo which looks nice. The latter needs to be written in a funky way: git cmd --abbrev= $foo if we take "empty parameter to a flag that take optional parameter means use the default setting"; we could introduce a magic 'default' token to read it slightly better: git cmd --abbrev=default $foo but that does not change the fact that it makes it harder for scripters. I do not disagree with that. The command line end users, who want to do the same, but has a bit more concrete than unknown $n, $cnt, or $foo, can do git cmd --abbrev HEAD~4 in either approach. However, with Pierre's, the command line end users can say either: git cmd --abbrev=10 -n=4 git cmd --abbrev=10 -n 4 git cmd --abbrev=10 -n4 but they cannot say: git cmd --abbrev 10 -n 4 They need to learn the difference between --abbrev and -n, because you avoid DWIMmery for the sake of script writers. I have a slight suspicion that it is backwards. If there is _no_ existing users and previous versions of git, one plausible alternative that would be much cleaner than anything we discussed so far would be to always require '-n=4' (or "-n4") form and never accept "-n 4", even for a flag that takes mandatory parameter. Then there is no room for confusion. Users (both command line end users and script writers) need to learn only one rule: flag parameters are always with the flag, not given as two words. I really wish the world were that simple, but I do no think that would fly well with the existing users' fingers. - 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
