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

From: Jeff King <peff@peff.net>
Date: Dec 7, 2020, 18:55 UTC
Message-ID: <X856rSHziQcmr/zX@coredump.intra.peff.net>
In-Reply-To: <xmqqa6upbgil.fsf@gitster.c.googlers.com>

On Mon, Dec 07, 2020 at 10:46:58AM -0800, Junio C Hamano wrote:

Show 10 quoted lines

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

Personally, I find "-linefoo" totally unreadable (and in general I find the "stuck" form of short options with a string to be pretty ugly, though I understand it is the recommended form to handle optional arguments). But "-line foo" is not so horrible IMHO, and I think it would be sad to lose it. (I don't use it with grep, but my standard perl invocation is "perl -lpe 'some script'"; another common one is "tar xvf foo.tar").

And it works now (obviously not in the case we're discussing, but in other cases that don't run afoul of the typo fix), so I think people would see that as a regression.

-Peff