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

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

Michael J Gruber <git@drmicha.warpmail.net> writes:

>> Similarly I think it is not very consistent that one cannot combine any of
>> the above options with the "S<string>" but instead have yet another option
>> called "pickaxe-regex" to toggle between "fixed-string" and
>> "extended-regexp" semantics for the argument passed to option "S".
>
> The defaults are different, and it is likely that users want to switch
> one without switching the other.
>
> E.g., with -S you often use strings that you'd rather not have to quote
> to guard them against the regexp engine.

But the hypothetical -G that would look for a fixed string would be
vastly different from -S, wouldn't it?

The -S<string> option was invented to find a commit where one side
of the comparison has that string in the blob and the other side
does not; it shows commits where <string> appears different number
of times in the before- and the after- blobs, because doing so does
not hurt its primary use case to find commits where one side has one
instance of <string> and the other side has zero.

But -G<regexp> shows commits whose "git show $that_commit" output
would have lines matching <regexp> as added or deleted.  So you get
different results from this history:

    (before)    (after)    
    a           b          
    b           a          
    c           c         

As "git show" for such a commit looks like this:

diff --git a/one b/one
index de98044..0c81c28 100644
--- a/one
+++ b/one
@@ -1,3 +1,3 @@
-a
 b
+a
 c

"git log -Ga" would say it is a match.  But from "git log -Sa"'s
point of view, it is not a match; both sides have the same number of
'a' [*1*].

I think it would make sense to teach --fixed-strings or whatever
option to -G just like it pays attention to ignore-case, but "-G
--fixed-strings" cannot be "-S".  They have different semantics.


[Footnote]

*1* This is because -S was envisioned as (and its behaviour has been
    maintained as such) a building block for Porcelain that does
    more than "git blame".  You feed a _unique_ block of lines taken
    from the current contents as the <string> to quickly find the
    last commit that touched that area, and iteratively dig deeper.
    The -S option was meant to be used for that single step of
    digging, as a part of much more grand vision in $gmane/217,
    which I would still consider one of the most important messages
    on the mailing list, posted 10 years ago ;-)