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

On Fri, Apr 17, 2015 at 7:26 AM, Michael J Gruber
[off-list ref] wrote:

quoted

quoted

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.