git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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 17, 2015, 14:26 UTC
Message-ID
<55311831.6010004@drmicha.warpmail.net>
In-Reply-To
<1090496912.6338.1429264855691.JavaMail.open-xchange@ox1app>
Tim Friske venit, vidit, dixit 17.04.2015 12:00:
Show 15 quoted lines
> 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
Previous: Tim FriskeNext: Junio C Hamano
Message 2 of 12 in “Why does "git log -G<regex>" works with "regexp-ignore-case" but not with other regexp-related options?”
  1. Tim FriskeApr 17, 2015
  2. Michael J GruberApr 17, 2015
  3. Junio C HamanoApr 17, 2015
  4. Junio C HamanoApr 17, 2015
  5. Junio C HamanoApr 17, 2015
  6. Michael J GruberApr 20, 2015
  7. Junio C HamanoApr 20, 2015
  8. Linus TorvaldsApr 20, 2015
  9. Junio C HamanoApr 20, 2015
  10. Michael J GruberApr 21, 2015
  11. Junio C HamanoApr 21, 2015
  12. Michael J GruberApr 22, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.