From: Michael J Gruber <git@drmicha•warpmail.net>
To: Tim Friske <me@tifr•de>, git <git@vger•kernel.org>
Subject: Re: Why does "git log -G<regex>" works with "regexp-ignore-case" but not with other regexp-related options?
Date: Fri, 17 Apr 2015 16:26:57 +0200 [thread overview]
Message-ID: <55311831.6010004@drmicha.warpmail.net> (raw)
In-Reply-To: <1090496912.6338.1429264855691.JavaMail.open-xchange@ox1app>
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
next prev parent reply other threads:[~2015-04-17 14:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-17 10:00 Why does "git log -G<regex>" works with "regexp-ignore-case" but not with other regexp-related options? Tim Friske
2015-04-17 14:26 ` Michael J Gruber [this message]
2015-04-17 16:18 ` Junio C Hamano
2015-04-17 17:09 ` Junio C Hamano
2015-04-17 17:45 ` Junio C Hamano
2015-04-20 8:49 ` Michael J Gruber
2015-04-20 17:41 ` Junio C Hamano
2015-04-20 18:33 ` Linus Torvalds
2015-04-20 18:44 ` Junio C Hamano
2015-04-21 8:41 ` Michael J Gruber
2015-04-21 16:59 ` Junio C Hamano
2015-04-22 9:08 ` Michael J Gruber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55311831.6010004@drmicha.warpmail.net \
--to=git@drmicha$(echo .)warpmail.net \
--cc=git@vger$(echo .)kernel.org \
--cc=me@tifr$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox