Jeff King <peff@xxxxxxxx> writes: > The problem is that it gives bundled short options a lower precedence > than detecting possible typos against long options. My instinct is to > say that this is wrong. We should allow valid things to work, and only > add error heuristics if the user's request is nonsense (i.e., if one of > the bundled options is not a valid one). Thanks, I was coming to the same conclusion. > But that actually contradicts > the original example given in 3a9f0f41db! There it was trying to make: > > git commit -amend > > an error. But that's a set of valid options, the same as: > > git commit -a -m end > > So we'd be losing that protection. Another option would be to make the > typo-checker a little more picky: > > - require more than 3 characters; this is just punting off the > problem, though. Doing "-line foo" is valid. So is "-linefoo", for > that matter, though that one would do what we want since it stops > being a prefix. > > - be more aggressive about how much of a long option we match in the > prefix (at least for the typo checker). "lin" is an awfully small > part of "line-number". People may plausibly use "--lin" or "--line" > as a shortcut, but I'm not sure that merits blocking the valid > "-lin" for the typo-checker. > > Either of those would let "-amend" continue to be an error, but fix > "-lin". I am wondering if a rule like "you cannot concatenate a short option that takes argument with other short options" work. The problem with "-a -m end" is really that the 'm' takes arbitrary end-user input. So "commit -ave" would be fine, but "commit -ame" would not be. This would make both "-line foo" and "--linefoo" consistently invalid, but "-lin -e foo" is still OK and make the rule easier to explain. Then we can probably lift the "more than 3 characters" heuristics, which may be a good thing independently.
