Re: Why does "git log -G<regex>" works with "regexp-ignore-case" but not with other regexp-related options?

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Apr 21, 2015, 08:41 UTC
Message-ID: <55360D3D.3010201@drmicha.warpmail.net>
In-Reply-To: <xmqqtwwaljwb.fsf@gitster.dls.corp.google.com>

Junio C Hamano venit, vidit, dixit 20.04.2015 20:44:

Show 22 quoted lines

> Linus Torvalds <torvalds@linux-foundation.org> writes:
> 
>> And to clarify: I don't suggest always building with libpcre. I
>> literally suggest having something like
>>
>>      /* hacky mac-hack hack */
>>     if (strncmp("(?i)", p->pattern, 4)) {
>>         p->pattern += 4;
>>         p->ignore_case = true;
>>     }
>>
>> just in front of the "regcomp() call, and nothing more fancy than that.
> 
> Yeah, looking at the way grep.c:compile_regexp() is structured, we
> are already prepared to allow
> 
>     $ git log --grep='(?i)torvalds' --grep='Linus'
> 
> that wants to find one piece of text case insensitively while
> another case sensitively in the same text (i.e. the log message
> part), so per-pattern customization may be a good way to do this.
>

And '(?f)foo' switches to fixed strings ;)

We have engine-switching options and engine-modification options. The latter are certainly good in the expression itself. Maybe even the former, though I don't know how to switch away from fixed-strings in that way...

I had forgotten about pcre. Maybe switching options independently is so unusual that "use pcre" is good enough as a solution to suggest to those few users?

In any case, that leaves us with:

- resolve the existing inconsistencies around --regexp-ignore-case
- allow to switch the engine for all greppy operations

Maybe have all command line options apply to all greppy ops as a first step, which allows pcre and thus '(?i)' for all fields?

Michael