From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by dcvr.yhbt.net (Postfix) with ESMTP id 2D0851F47C for ; Thu, 12 Jan 2023 22:08:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239706AbjALWHP (ORCPT ); Thu, 12 Jan 2023 17:07:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55616 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239906AbjALWGZ (ORCPT ); Thu, 12 Jan 2023 17:06:25 -0500 Received: from cloud.peff.net (cloud.peff.net [104.130.231.41]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 252D476AD7 for ; Thu, 12 Jan 2023 13:54:55 -0800 (PST) Received: (qmail 8387 invoked by uid 109); 12 Jan 2023 21:54:55 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Thu, 12 Jan 2023 21:54:55 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 19695 invoked by uid 111); 12 Jan 2023 21:54:56 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Thu, 12 Jan 2023 16:54:56 -0500 Authentication-Results: peff.net; auth=none Date: Thu, 12 Jan 2023 16:54:54 -0500 From: Jeff King To: =?utf-8?B?UmVuw6k=?= Scharfe Cc: Marco Nenciarini , git@vger.kernel.org, Junio C Hamano , =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason Subject: Re: BUG: git grep behave oddly with alternatives Message-ID: References: <634f47a8-b370-81cb-00e7-d93ffc7534a8@web.de> <1f61b660-b2d0-ba93-3182-05a9ab97b00e@enterprisedb.com> <343a891e-d737-0ace-26a9-3839d3bd5583@web.de> <26a0d4ca-3d97-ace4-1a1f-92b1ee6715a6@web.de> <4165031d-e7f1-0477-2245-6a8e312de522@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4165031d-e7f1-0477-2245-6a8e312de522@web.de> Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Thu, Jan 12, 2023 at 06:13:13PM +0100, René Scharfe wrote: > > I'm not quite sure what you mean here by "non-greedy repetitions". > > Something like: > > > > # prefer "foo bar" to "foo bar bar"; only matters for colorizing or > > # --only-matching > > git grep -E 'foo.*?bar' > > > > ? If so, then yeah, that changes the meaning of a bare "?" and people > > might be surprised by it. > > Right. To be fair, question mark is a special character and you'd > probably need to quote it anyway if you want to match a literal > question mark. Otherwise I get: > > $ git grep -E 'foo.*?bar' > fatal: command line, 'foo.*?bar': repetition-operator operand invalid This is on macOS, I assume? With glibc it seems to be quietly ignored: $ git grep -E -o 'foo.*?ba' .clang-format .clang-format:foo, bar, ba So it is not treated literally (as it would be without -E). But nor does it make the match non-greedy (otherwise it would have output "foo, ba", as "git grep -P" does). So it does seem like all bets are off for what people can and should expect here. Which isn't to say we should make things worse. I mostly wondered if REG_ENHANCED might take us closer to what glibc was doing by default, but it doesn't seem like it. -Peff