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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> 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.