Junio C Hamano venit, vidit, dixit 17.04.2015 19:45: > On Fri, Apr 17, 2015 at 7:26 AM, Michael J Gruber > <git@xxxxxxxxxxxxxxxxxxxx> wrote: >>> >>> 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. 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.] > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html