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

From: Michael J Gruber <[email-masked]>
Date: Tue, 21 Apr 2015 10:41:33 +0200

Junio C Hamano venit, vidit, dixit 20.04.2015 20:44:
> Linus Torvalds <[email-masked]> 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