GNU bug report logs - #36644
Git log search

Previous Next

Package: emacs;

Reported by: Juri Linkov <juri <at> linkov.net>

Date: Sat, 13 Jul 2019 22:32:02 UTC

Severity: wishlist

Tags: fixed

Fixed in version 27.0.50

Done: Juri Linkov <juri <at> linkov.net>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: 36644 <at> debbugs.gnu.org
Subject: bug#36644: Git log search
Date: Thu, 18 Jul 2019 18:01:12 +0300
On 16.07.2019 23:15, Juri Linkov wrote:

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

What do you mean, "the need"? If it's a verbatim string, we should 
escape characters that have special meaning in regexps (or do like 
Andreas suggested and pass --fixed-string to 'git log'). If it's a 
regexp, we should document it as such.

>>>> 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.

That is true. If Hg or Bzr support regexp search as well, we might want 
to choose it to be a regexp. And kind of give up on the rest 
(unsupported, etc).

>>>> 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. 

That would be a different command, or...? Anyway, the idea sounds nice.

> 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.

Maybe we shouldn't allow Perl extensions. Or, IDK, give up on 
highlighting in that particular case.

>>> 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.

FWIW, I prefer commands to have shorter bindings, when possible. Using 
prefix keys too much tends to conflict with that.




This bug report was last modified 6 years and 25 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.