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

Hi,

I wonder why  "git log -G<regexp>" works with the "regexp-ignore-case"
option but not with the other regexp-related options? Wouldn't it be
useful to make the "G<regex>" option support the following options?

  * basic-regexp
  * extended-regexp
  * fixed-strings
  * perl-regexp

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 description of the above options in the git-log(1) manpage of Git
version 2.1 do not explicitly say that they do not support the "G<regex>"
and "S<string>" option.

Wouldn't it be nice to have all of the above options collaborate with each
other?

Tim Friske venit, vidit, dixit 17.04.2015 12:00:

Hi,

I wonder why  "git log -G<regexp>" works with the "regexp-ignore-case"
option but not with the other regexp-related options? Wouldn't it be
useful to make the "G<regex>" option support the following options?

  * basic-regexp
  * extended-regexp
  * fixed-strings
  * perl-regexp

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.

The description of the above options in the git-log(1) manpage of Git
version 2.1 do not explicitly say that they do not support the "G<regex>"
and "S<string>" option.

They are in different sections, since --grep etc. are log options
pertaining to matching the commit header and log message (commit
object), while S and G match in the diff and are described in the diff
section (although they are commit limitting as well).

Wouldn't it be nice to have all of the above options collaborate with each
other?

I'm afraid it's important to keep the different defaults.

Personally, I found it surprising that --regexp-ignore-case applies to
-G at all. It turns out that it was "bolted on" retroactively - it used
to apply to commit object greps only, and was made to switch also diff
grep behaviour later, as a convenience matter. The reason probaly is
that "-S" originally was directed at script usage and turned out to be
used by end users quite a bit.

I'd say most of our inconsistencies are due to convenience...

If you want to work on this, I suggest you introduce the missing long
option names such as "--grep-diff" (-G) and maybe "--grep-log" (--grep)
first and then find consistent and convenient names and defaults for the
regexp options.

Michael

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

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.


[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 ;-)



[jc: My mail provider seem to be queuing but not sending out SMTP
outgoing traffic, so I am trying to (re)send this in an alternate route.
If you got a duplicate of this message, my apologies.]

Junio C Hamano venit, vidit, dixit 17.04.2015 19:45:

Of course they cannot, that's not what I meant. They have different
semantics, and *therefore* they have different defaults, and *therefore*
a user may want to switch one of them (or --grep or --author or...) to
--fixed--strings and keep the other to --regexp.

One idea would be to make

--regexp -S --fixed-strings -G

work the obvious way (match option affects following grep options), but
we have position independent options for most commands. Alternatively,
we could distinguish at least between two groups of greppish operations
and let them have independent modifying arguments and defaults:

- commit header/object (--grep, --grep-reflog, --author, ...)
- diff (-S, -G)

But that would require some changes to current behavior.

[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 ;-)



[jc: My mail provider seem to be queuing but not sending out SMTP
outgoing traffic, so I am trying to (re)send this in an alternate route.
If you got a duplicate of this message, my apologies.]