{"thread":{"id":"39099","subject":"Why does \"git log -G\" works with \"regexp-ignore-case\" but not with other regexp-related options?","startedAt":"2015-04-17T10:00:55Z","lastAt":"2015-04-22T09:08:27Z","messageCount":12,"participants":["Tim Friske","Michael J Gruber","Junio C Hamano","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"259557","messageId":"1090496912.6338.1429264855691.JavaMail.open-xchange@ox1app","threadId":"39099","inReplyTo":null,"subject":"Why does \"git log -G\" works with \"regexp-ignore-case\" but not with other regexp-related options?","fromName":"Tim Friske","fromEmail":"me@tifr.de","sentAt":"2015-04-17T10:00:55Z","receivedAt":"2015-04-17T10:00:55Z","isPatch":false,"sender":{"key":"me@tifr.de","avatar":null},"body":"Hi,\n\nI wonder why \"git log -G\" works with the \"regexp-ignore-case\"\noption but not with the other regexp-related options? Wouldn't it be\nuseful to make the \"G\" option support the following options?\n\n * basic-regexp\n * extended-regexp\n * fixed-strings\n * perl-regexp\n\nSimilarly I think it is not very consistent that one cannot combine any of\nthe above options with the \"S\" but instead have yet another option\ncalled \"pickaxe-regex\" to toggle between \"fixed-string\" and\n\"extended-regexp\" semantics for the argument passed to option \"S\".\n\nThe description of the above options in the git-log(1) manpage of Git\nversion 2.1 do not explicitly say that they do not support the \"G\"\nand \"S\" option.\n\nWouldn't it be nice to have all of the above options collaborate with each\nother?\n"},{"id":"259564","messageId":"55311831.6010004@drmicha.warpmail.net","threadId":"39099","inReplyTo":"1090496912.6338.1429264855691.JavaMail.open-xchange@ox1app","subject":"Re: Why does \"git log -G\" works with \"regexp-ignore-case\" but not with other regexp-related options?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-04-17T14:26:57Z","receivedAt":"2015-04-17T14:26:57Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Tim Friske venit, vidit, dixit 17.04.2015 12:00:\n> Hi,\n> \n> I wonder why \"git log -G\" works with the \"regexp-ignore-case\"\n> option but not with the other regexp-related options? Wouldn't it be\n> useful to make the \"G\" option support the following options?\n> \n> * basic-regexp\n> * extended-regexp\n> * fixed-strings\n> * perl-regexp\n> \n> Similarly I think it is not very consistent that one cannot combine any of\n> the above options with the \"S\" but instead have yet another option\n> called \"pickaxe-regex\" to toggle between \"fixed-string\" and\n> \"extended-regexp\" semantics for the argument passed to option \"S\".\n\nThe defaults are different, and it is likely that users want to switch\none without switching the other.\n\nE.g., with -S you often use strings that you'd rather not have to quote\nto guard them against the regexp engine.\n\n> The description of the above options in the git-log(1) manpage of Git\n> version 2.1 do not explicitly say that they do not support the \"G\"\n> and \"S\" option.\n\nThey are in different sections, since --grep etc. are log options\npertaining to matching the commit header and log message (commit\nobject), while S and G match in the diff and are described in the diff\nsection (although they are commit limitting as well).\n\n> Wouldn't it be nice to have all of the above options collaborate with each\n> other?\n\nI'm afraid it's important to keep the different defaults.\n\nPersonally, I found it surprising that --regexp-ignore-case applies to\n-G at all. It turns out that it was \"bolted on\" retroactively - it used\nto apply to commit object greps only, and was made to switch also diff\ngrep behaviour later, as a convenience matter. The reason probaly is\nthat \"-S\" originally was directed at script usage and turned out to be\nused by end users quite a bit.\n\nI'd say most of our inconsistencies are due to convenience...\n\nIf you want to work on this, I suggest you introduce the missing long\noption names such as \"--grep-diff\" (-G) and maybe \"--grep-log\" (--grep)\nfirst and then find consistent and convenient names and defaults for the\nregexp options.\n\nMichael\n"},{"id":"259583","messageId":"xmqqh9sehgnr.fsf@gitster.dls.corp.google.com","threadId":"39099","inReplyTo":"55311831.6010004@drmicha.warpmail.net","subject":"Re: Why does \"git log -G\" works with \"regexp-ignore-case\" but not with other regexp-related options?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-04-17T16:18:48Z","receivedAt":"2015-04-17T16:18:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n>> Similarly I think it is not very consistent that one cannot combine any of\n>> the above options with the \"S\" but instead have yet another option\n>> called \"pickaxe-regex\" to toggle between \"fixed-string\" and\n>> \"extended-regexp\" semantics for the argument passed to option \"S\".\n>\n> The defaults are different, and it is likely that users want to switch\n> one without switching the other.\n>\n> E.g., with -S you often use strings that you'd rather not have to quote\n> to guard them against the regexp engine.\n\nBut the hypothetical -G that would look for a fixed string would be\nvastly different from -S, wouldn't it?\n\nThe -S option was invented to find a commit where one side\nof the comparison has that string in the blob and the other side\ndoes not; it shows commits where appears different number\nof times in the before- and the after- blobs, because doing so does\nnot hurt its primary use case to find commits where one side has one\ninstance of and the other side has zero.\n\nBut -G shows commits whose \"git show $that_commit\" output\nwould have lines matching as added or deleted. So you get\ndifferent results from this history:\n\n (before) (after) \n a b \n b a \n c c \n\nAs \"git show\" for such a commit looks like this:\n\ndiff --git a/one b/one\nindex de98044..0c81c28 100644\n--- a/one\n+++ b/one\n@@ -1,3 +1,3 @@\n-a\n b\n+a\n c\n\n\"git log -Ga\" would say it is a match. But from \"git log -Sa\"'s\npoint of view, it is not a match; both sides have the same number of\n'a' [*1*].\n\nI think it would make sense to teach --fixed-strings or whatever\noption to -G just like it pays attention to ignore-case, but \"-G\n--fixed-strings\" cannot be \"-S\". They have different semantics.\n\n\n[Footnote]\n\n*1* This is because -S was envisioned as (and its behaviour has been\n maintained as such) a building block for Porcelain that does\n more than \"git blame\". You feed a _unique_ block of lines taken\n from the current contents as the to quickly find the\n last commit that touched that area, and iteratively dig deeper.\n The -S option was meant to be used for that single step of\n digging, as a part of much more grand vision in $gmane/217,\n which I would still consider one of the most important messages\n on the mailing list, posted 10 years ago ;-)\n"},{"id":"259578","messageId":"xmqq7ftaheal.fsf@gitster.dls.corp.google.com","threadId":"39099","inReplyTo":"55311831.6010004@drmicha.warpmail.net","subject":"Re: Why does \"git log -G\" works with \"regexp-ignore-case\" but not with other regexp-related options?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-04-17T17:09:54Z","receivedAt":"2015-04-17T17:09:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n>> Similarly I think it is not very consistent that one cannot combine any of\n>> the above options with the \"S\" but instead have yet another option\n>> called \"pickaxe-regex\" to toggle between \"fixed-string\" and\n>> \"extended-regexp\" semantics for the argument passed to option \"S\".\n>\n> The defaults are different, and it is likely that users want to switch\n> one without switching the other.\n>\n> E.g., with -S you often use strings that you'd rather not have to quote\n> to guard them against the regexp engine.\n\nBut the hypothetical -G that would look for a fixed string would be\nvastly different from -S, wouldn't it?\n\nThe -S option was invented to find a commit where one side\nof the comparison has that string in the blob and the other side\ndoes not; it shows commits where appears different number\nof times in the before- and the after- blobs, because doing so does\nnot hurt its primary use case to find commits where one side has one\ninstance of and the other side has zero.\n\nBut -G shows commits whose \"git show $that_commit\" output\nwould have lines matching as added or deleted. So you get\ndifferent results from this history:\n\n (before) (after) \n a b \n b a \n c c \n\nAs \"git show\" for such a commit looks like this:\n\ndiff --git a/one b/one\nindex de98044..0c81c28 100644\n--- a/one\n+++ b/one\n@@ -1,3 +1,3 @@\n-a\n b\n+a\n c\n\n\"git log -Ga\" would say it is a match. But from \"git log -Sa\"'s\npoint of view, it is not a match; both sides have the same number of\n'a' [*1*].\n\nI think it would make sense to teach --fixed-strings or whatever\noption to -G just like it pays attention to ignore-case, but \"-G\n--fixed-strings\" cannot be \"-S\". They have different semantics.\n\n\n[Footnote]\n\n*1* This is because -S was envisioned as (and its behaviour has been\n maintained as such) a building block for Porcelain that does\n more than \"git blame\". You feed a _unique_ block of lines taken\n from the current contents as the to quickly find the\n last commit that touched that area, and iteratively dig deeper.\n The -S option was meant to be used for that single step of\n digging, as a part of much more grand vision in $gmane/217,\n which I would still consider one of the most important messages\n on the mailing list, posted 10 years ago ;-)\n"},{"id":"259577","messageId":"CAPc5daUULhhV0+kL_htLnA8Z_woFLjxg_pO_cB0KLAMuxJnsMQ@mail.gmail.com","threadId":"39099","inReplyTo":"55311831.6010004@drmicha.warpmail.net","subject":"Re: Why does \"git log -G\" works with \"regexp-ignore-case\" but not with other regexp-related options?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-04-17T17:45:42Z","receivedAt":"2015-04-17T17:45:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Fri, Apr 17, 2015 at 7:26 AM, Michael J Gruber\n wrote:\n>>\n>> Similarly I think it is not very consistent that one cannot combine any of\n>> the above options with the \"S\" but instead have yet another option\n>> called \"pickaxe-regex\" to toggle between \"fixed-string\" and\n>> \"extended-regexp\" semantics for the argument passed to option \"S\".\n>\n> The defaults are different, and it is likely that users want to switch\n> one without switching the other.\n>\n> E.g., with -S you often use strings that you'd rather not have to quote\n> to guard them against the regexp engine.\n\nBut the hypothetical -G that would look for a fixed string would be\nvastly different from -S, wouldn't it?\n\nThe -S option was invented to find a commit where one side\nof the comparison has that string in the blob and the other side\ndoes not; it shows commits where appears different number\nof times in the before- and the after- blobs, because doing so does\nnot hurt its primary use case to find commits where one side has one\ninstance of and the other side has zero.\n\nBut -G shows commits whose \"git show $that_commit\" output\nwould have lines matching as added or deleted. So you get\ndifferent results from this history:\n\n (before) (after)\n a b\n b a\n c c\n\nAs \"git show\" for such a commit looks like this:\n\ndiff --git a/one b/one\nindex de98044..0c81c28 100644\n--- a/one\n+++ b/one\n@@ -1,3 +1,3 @@\n-a\n b\n+a\n c\n\n\"git log -Ga\" would say it is a match. But from \"git log -Sa\"'s\npoint of view, it is not a match; both sides have the same number of\n'a' [*1*].\n\nI think it would make sense to teach --fixed-strings or whatever\noption to -G just like it pays attention to ignore-case, but \"-G\n--fixed-strings\" cannot be \"-S\". They have different semantics.\n\n\n[Footnote]\n\n*1* This is because -S was envisioned as (and its behaviour has been\n maintained as such) a building block for Porcelain that does\n more than \"git blame\". You feed a _unique_ block of lines taken\n from the current contents as the to quickly find the\n last commit that touched that area, and iteratively dig deeper.\n The -S option was meant to be used for that single step of\n digging, as a part of much more grand vision in $gmane/217,\n which I would still consider one of the most important messages\n on the mailing list, posted 10 years ago ;-)\n\n\n\n[jc: My mail provider seem to be queuing but not sending out SMTP\noutgoing traffic, so I am trying to (re)send this in an alternate route.\nIf you got a duplicate of this message, my apologies.]\n"},{"id":"259665","messageId":"5534BD87.8020709@drmicha.warpmail.net","threadId":"39099","inReplyTo":"CAPc5daUULhhV0+kL_htLnA8Z_woFLjxg_pO_cB0KLAMuxJnsMQ@mail.gmail.com","subject":"Re: Why does \"git log -G\" works with \"regexp-ignore-case\" but not with other regexp-related options?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-04-20T08:49:11Z","receivedAt":"2015-04-20T08:49:11Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 17.04.2015 19:45:\n> On Fri, Apr 17, 2015 at 7:26 AM, Michael J Gruber\n> wrote:\n>>>\n>>> Similarly I think it is not very consistent that one cannot combine any of\n>>> the above options with the \"S\" but instead have yet another option\n>>> called \"pickaxe-regex\" to toggle between \"fixed-string\" and\n>>> \"extended-regexp\" semantics for the argument passed to option \"S\".\n>>\n>> The defaults are different, and it is likely that users want to switch\n>> one without switching the other.\n>>\n>> E.g., with -S you often use strings that you'd rather not have to quote\n>> to guard them against the regexp engine.\n> \n> But the hypothetical -G that would look for a fixed string would be\n> vastly different from -S, wouldn't it?\n> \n> The -S option was invented to find a commit where one side\n> of the comparison has that string in the blob and the other side\n> does not; it shows commits where appears different number\n> of times in the before- and the after- blobs, because doing so does\n> not hurt its primary use case to find commits where one side has one\n> instance of and the other side has zero.\n> \n> But -G shows commits whose \"git show $that_commit\" output\n> would have lines matching as added or deleted. So you get\n> different results from this history:\n> \n> (before) (after)\n> a b\n> b a\n> c c\n> \n> As \"git show\" for such a commit looks like this:\n> \n> diff --git a/one b/one\n> index de98044..0c81c28 100644\n> --- a/one\n> +++ b/one\n> @@ -1,3 +1,3 @@\n> -a\n> b\n> +a\n> c\n> \n> \"git log -Ga\" would say it is a match. But from \"git log -Sa\"'s\n> point of view, it is not a match; both sides have the same number of\n> 'a' [*1*].\n> \n> I think it would make sense to teach --fixed-strings or whatever\n> option to -G just like it pays attention to ignore-case, but \"-G\n> --fixed-strings\" cannot be \"-S\". They have different semantics.\n\nOf course they cannot, that's not what I meant. They have different\nsemantics, and *therefore* they have different defaults, and *therefore*\na user may want to switch one of them (or --grep or --author or...) to\n--fixed--strings and keep the other to --regexp.\n\nOne idea would be to make\n\n--regexp -S --fixed-strings -G\n\nwork the obvious way (match option affects following grep options), but\nwe have position independent options for most commands. Alternatively,\nwe could distinguish at least between two groups of greppish operations\nand let them have independent modifying arguments and defaults:\n\n- commit header/object (--grep, --grep-reflog, --author, ...)\n- diff (-S, -G)\n\nBut that would require some changes to current behavior.\n\n> [Footnote]\n> \n> *1* This is because -S was envisioned as (and its behaviour has been\n> maintained as such) a building block for Porcelain that does\n> more than \"git blame\". You feed a _unique_ block of lines taken\n> from the current contents as the to quickly find the\n> last commit that touched that area, and iteratively dig deeper.\n> The -S option was meant to be used for that single step of\n> digging, as a part of much more grand vision in $gmane/217,\n> which I would still consider one of the most important messages\n> on the mailing list, posted 10 years ago ;-)\n> \n> \n> \n> [jc: My mail provider seem to be queuing but not sending out SMTP\n> outgoing traffic, so I am trying to (re)send this in an alternate route.\n> If you got a duplicate of this message, my apologies.]\n> \n"},{"id":"259685","messageId":"xmqqbniin1cw.fsf@gitster.dls.corp.google.com","threadId":"39099","inReplyTo":"5534BD87.8020709@drmicha.warpmail.net","subject":"Re: Why does \"git log -G\" works with \"regexp-ignore-case\" but not with other regexp-related options?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-04-20T17:41:51Z","receivedAt":"2015-04-20T17:41:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> They [jc: -S and -G] have different semantics, and *therefore*\n> they have different defaults, and *therefore* a user may want to\n> switch one of them (or --grep or --author or...) to\n> --fixed--strings and keep the other to --regexp.\n\nAhh, OK. And not just -S and -G, the \"fields in headers\" may be\nsomething user may want to switch independently?\n\n> One idea would be to make\n>\n> --regexp -S --fixed-strings -G\n>\n> work the obvious way (match option affects following grep\n> options),...\n\nI understand that your idea is for options to accumulate up to what\nconsumes them, e.g. -S, -G, --author,..., and then get reset for the\nnext consumer. I would think it is very much debatable if that way\nof working is \"the obvious\" one, though. If I had no prior Git\nexperience, I would imagine that I would find it more intuitive if\n\n $ git log --regexp-ignore-case --author=tiM --grep=wip\n\nshowed a commit authored by Tim that is labelled with \"[WIP]\".\n\nIt may be tempting to expose that our underlying machinery could use\n3 different regexp matching settings for header fields (i.e. author,\ncommitter), log messages and the patch bodies somehow to the end\nusers, and either interpreting options position-dependently or\nhaving separate options may be possible ways to do so. That would\ngive the end users full flexibility the underlying machinery offers.\n\nI am however not yet convinced that additional complexity at the UI\nlevel that would burden the end users is a reasonable price to pay\nfor such a flexibility. When was the last time you wanted to grep\nfor log messages case insensitively for commits authored by Tim but\nwanted to hide commits authored by tim when you used the above \"log\"\ncommand line or similar?\n"},{"id":"259690","messageId":"CA+55aFzdSgvYo11PHamkOVASz61RUq26+s0na0Zh2RRwsEkrMg@mail.gmail.com","threadId":"39099","inReplyTo":"xmqqbniin1cw.fsf@gitster.dls.corp.google.com","subject":"Re: Why does \"git log -G\" works with \"regexp-ignore-case\" but not with other regexp-related options?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2015-04-20T18:33:31Z","receivedAt":"2015-04-20T18:33:31Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Mon, Apr 20, 2015 at 10:41 AM, Junio C Hamano wrote:\n>\n> Ahh, OK. And not just -S and -G, the \"fields in headers\" may be\n> something user may want to switch independently?\n\nSo personally, I hate extra command line flags for this. I'd much\nrather see is use something in the regular expression itself, and make\n*that* be the way you do it, and make it be the preferred format.\n\nOtherwise, you'll always have the issue that you want *part* to be\ncase-ignoring, and another entry not, and then it's just messy with\nthe \"ignore case\" being some other thing.\n\nAnd we support that with perl regexps, but those are only enabled with\nlibpcre. I wonder if we could just make some simple pattern extension\nthat we make work even *without* libpcre.\n\nIOW, instead of making people use \"-regexp-ignore-case\", could we just\nsay that we *always* support the syntax of appending \"(?i)\" in front\nof the regexp. So that your\n\n git log --regexp-ignore-case --author=tiM --grep=wip\n\nexample would be\n\n git log --author=\"(?i)tiM\" --grep=wip\n\nand it would match the _author_ with ignoring case, but the\n\"--grep=wip\" part would be an exact grep.\n\nRight now the above already works (I think) if you:\n\n - build with USE_LIBPCRE\n\n - add that \"--perl-regexp\" switch.\n\nbut what I'm suggesting is that we'd make a special case for the\nmagical perl modifier pattern at the beginning for \"(?i)\", and make it\nwork even without USE_LIBPCRE, and without specifying \"--perl-regexp\".\n\nWe'd just special-case that pattern (and perhaps _only_ that special\nfour-byte sequence of \"(?i)\" at the beginning of the search string),\nbut perhaps we could support '(?s)' too?\n\nHmm? I realize that this would be theoretically an incompatible\nchange, but it would be very convenient and if we document it well it\nmight be ok. I doubt people really search for \"(?i)\" at the beginning\nof strings _except_ if they already know about the perl syntax and\nwant it.\n\nAnd to clarify: I don't suggest always building with libpcre. I\nliterally suggest having something like\n\n /* hacky mac-hack hack */\n if (strncmp(\"(?i)\", p->pattern, 4)) {\n p->pattern += 4;\n p->ignore_case = true;\n }\n\njust in front of the \"regcomp() call, and nothing more fancy than that.\n\n Linus\n"},{"id":"259692","messageId":"xmqqtwwaljwb.fsf@gitster.dls.corp.google.com","threadId":"39099","inReplyTo":"CA+55aFzdSgvYo11PHamkOVASz61RUq26+s0na0Zh2RRwsEkrMg@mail.gmail.com","subject":"Re: Why does \"git log -G\" works with \"regexp-ignore-case\" but not with other regexp-related options?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-04-20T18:44:20Z","receivedAt":"2015-04-20T18:44:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> And to clarify: I don't suggest always building with libpcre. I\n> literally suggest having something like\n>\n> /* hacky mac-hack hack */\n> if (strncmp(\"(?i)\", p->pattern, 4)) {\n> p->pattern += 4;\n> p->ignore_case = true;\n> }\n>\n> just in front of the \"regcomp() call, and nothing more fancy than that.\n\nYeah, looking at the way grep.c:compile_regexp() is structured, we\nare already prepared to allow\n\n $ git log --grep='(?i)torvalds' --grep='Linus'\n\nthat wants to find one piece of text case insensitively while\nanother case sensitively in the same text (i.e. the log message\npart), so per-pattern customization may be a good way to do this.\n"},{"id":"259728","messageId":"55360D3D.3010201@drmicha.warpmail.net","threadId":"39099","inReplyTo":"xmqqtwwaljwb.fsf@gitster.dls.corp.google.com","subject":"Re: Why does \"git log -G\" works with \"regexp-ignore-case\" but not with other regexp-related options?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-04-21T08:41:33Z","receivedAt":"2015-04-21T08:41:33Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 20.04.2015 20:44:\n> Linus Torvalds writes:\n> \n>> And to clarify: I don't suggest always building with libpcre. I\n>> literally suggest having something like\n>>\n>> /* hacky mac-hack hack */\n>> if (strncmp(\"(?i)\", p->pattern, 4)) {\n>> p->pattern += 4;\n>> p->ignore_case = true;\n>> }\n>>\n>> just in front of the \"regcomp() call, and nothing more fancy than that.\n> \n> Yeah, looking at the way grep.c:compile_regexp() is structured, we\n> are already prepared to allow\n> \n> $ git log --grep='(?i)torvalds' --grep='Linus'\n> \n> that wants to find one piece of text case insensitively while\n> another case sensitively in the same text (i.e. the log message\n> part), so per-pattern customization may be a good way to do this.\n> \n\nAnd '(?f)foo' switches to fixed strings ;)\n\nWe have engine-switching options and engine-modification options. The\nlatter are certainly good in the expression itself. Maybe even the\nformer, though I don't know how to switch away from fixed-strings in\nthat way...\n\nI had forgotten about pcre. Maybe switching options independently is so\nunusual that \"use pcre\" is good enough as a solution to suggest to those\nfew users?\n\nIn any case, that leaves us with:\n\n- resolve the existing inconsistencies around --regexp-ignore-case\n- allow to switch the engine for all greppy operations\n\nMaybe have all command line options apply to all greppy ops as a first\nstep, which allows pcre and thus '(?i)' for all fields?\n\nMichael\n"},{"id":"259739","messageId":"xmqqr3rdific.fsf@gitster.dls.corp.google.com","threadId":"39099","inReplyTo":"55360D3D.3010201@drmicha.warpmail.net","subject":"Re: Why does \"git log -G\" works with \"regexp-ignore-case\" but not with other regexp-related options?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-04-21T16:59:39Z","receivedAt":"2015-04-21T16:59:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> We have engine-switching options and engine-modification options. The\n> latter are certainly good in the expression itself. Maybe even the\n> former, though I don't know how to switch away from fixed-strings in\n> that way...\n\nI do not think mixing matching engines in a single request makes\nmuch sense. As the internal machinery is not even prepared to do\nthat, even though it is prepared to apply engine-modifications ones\nto each grep term AFAIK, let's not go there.\n"},{"id":"259789","messageId":"5537650B.5050505@drmicha.warpmail.net","threadId":"39099","inReplyTo":"xmqqr3rdific.fsf@gitster.dls.corp.google.com","subject":"Re: Why does \"git log -G\" works with \"regexp-ignore-case\" but not with other regexp-related options?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-04-22T09:08:27Z","receivedAt":"2015-04-22T09:08:27Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 21.04.2015 18:59:\n> Michael J Gruber writes:\n> \n>> We have engine-switching options and engine-modification options. The\n>> latter are certainly good in the expression itself. Maybe even the\n>> former, though I don't know how to switch away from fixed-strings in\n>> that way...\n> \n> I do not think mixing matching engines in a single request makes\n> much sense. As the internal machinery is not even prepared to do\n> that, even though it is prepared to apply engine-modifications ones\n> to each grep term AFAIK, let's not go there.\n> \n\n>From a user perspective, we mix engines already: fixed strings for -S,\nregexp for the rest (by default). The user can switch one, but not the\nother. And there are options that modify both engines at the same time.\nThat is the kind of confusion that (triggered OP's request and that) I\nwould like to resolve.\n\nMichael\n"}]}