Re: `git grep` is too picky about option parsing

> 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).

> 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".