bug#36644: Git log search

[Dmitry Gutov <dgutov@yandex.ru>]

On 24.07.2019 19:13, Eli Zaretskii wrote:

>> Eli, could you weigh in in this discussion? Would you say Robert's
>> proposal is acceptable?
> 
> Yes, I think on balance it's acceptable.

OK, thank you.

> I also see your point: it would be nice to be able to document the
> semantics of PATTERN in a backend-independent way.  But I think this
> is next to impossible in this case, both because of significant
> differences in the backend capabilities (e.g., bzr doesn't have the
> equivalent of Git's --fixed-strings, AFAICT), and because some backend
> allow great flexibility in interpreting PATTERN, under control of
> optional switches passed to the backend.

The other option is to standardize on basic or extended regexp, and 
simply give up for backends that can't support that.

Git supports all kinds of regexps. 'hg grep' uses Perl-compatible ones 
(meaning extended regexps are supported, at least). I'm not sure which 
regular expressions are expected by 'bzr log -match', but if it doesn't 
support the extended ones, *shrug*.

As for the older VCS-es, some probably don't support search at all. And 
we've lived without such support for decades, so supporting them can't 
be too important.

Anyway, if people disagree, I'm not going to press the issue.

> So I think we should treat this as we do in "M-x grep": leave the
> semantics of PATTERN backend-dependent, and rely on the user to quote
> some characters in it as needed.  Admittedly, 'grep' is lower-level
> than 'vc-log-search', but at least we have a precedent.

The difference is, 'M-x grep' doesn't use different backends. Although 
I'd be happy to see that capability.

> Note that I still think we should use PATTERN, not STRING in the doc
> string, because a literal string here is more an exception than a
> rule.  But we should say that the exact semantics of PATTERN is
> backend-dependent, and perhaps describe how a couple of the more
> popular backends interpret it.

Makes sense.