bug#36644: Git log search

[Juri Linkov]

>>> Is pattern a regexp or a verbatim string? That should be documented.
>>
>> Fixed to use string.
>
> Since --grep expects a regexp, shouldn't PATTERN be passed through
> regexp-quote as well? Though it expects Emacs regexps, so it doesn't quote
> parens or pipes.

Should this still be used when the need is to pass regexps to the backend
search command verbatim?

>>> Git supports regexps, but maybe we should look at what other backends
>>> can support as well.
>>
>> It seems the most compatible type is string.
>
> OK, if that is your conclusion.

I'm still not sure.  Regexps are more useful.

>>> I wonder if the format of the output should be specified as well.
>>> E.g. by saying that it's the same as for print-log, long version.
>>
>> Fixed by saying it's long version.
>>
>> Should it support short format as well?
>
> I don't know. How would it be used?

Short format displays one line per entry and allows expanding
after pressing RET.  OTOH, when using long format we could highlight
all matches in log entries that will be immediately visible
after the command finishes (like in vc-git-grep output buffers).

However, when allowed to use regexp patterns, I don't know how to
highlight matches in git-log output buffer using Emacs regexps
when pattern uses e.g. Perl-compatible regexp allowed in git-log.

>> Should it have a key binding?
>>
>> For example, `vc-log-incoming' is bound to `C-x v I',
>> `vc-log-outgoing' is bound to key `C-x v O', so logically
>> `vc-log-search' would be bound to `C-x v s', but unfortunately
>> it's already taken by `vc-create-tag'.
>
> 'C-x v S', then?

This is good mnemonic keybinding.  The only doubt when adding a new
keybinding is to think if it could be more useful as a prefix key.
Maybe in this case upper-case shifted 'S' is not good as a prefix key.
Otherwise such prefix key could accommodate other vc search related
commands like grep vc files, etc.