Michael J Gruber <[email protected]> writes:
>> 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 ;-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
