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: Robert Pluim <rpluim <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, "36644 <at> debbugs.gnu.org" <36644 <at> debbugs.gnu.org>, Juri Linkov <juri <at> linkov.net>
Subject: bug#36644: Git log search
Date: Wed, 24 Jul 2019 18:53:01 +0300
On 24.07.2019 18:46, Robert Pluim wrote:
>>>>>> On Wed, 24 Jul 2019 18:10:35 +0300, Dmitry Gutov <dgutov <at> yandex.ru> said:
> 
>      Dmitry> On 19.07.2019 1:32, Juri Linkov wrote:
>      >>> We can't really use this approach. VC is a high level abstraction,
>      >>> so we try to define the semantics well.
>      >>
>      >> I tend to agree with Robert.  A string have to be passed to the backend as is.
>      >> It seems such situations when these strings should be compatible between
>      >> different backends (such as running the same command on one backend,
>      >> and then repeating the same search on another backend by retrieving
>      >> a previous argument from the history via M-p) are very rare.
> 
>      Dmitry> I might agree with you from the practical standpoint, but
>      Dmitry> vc-log-search needs a docstring that actually describes what the
>      Dmitry> function is going to do. Including info on how PATTERN is going to be
>      Dmitry> interpreted.
> 
> If it were implemented as 'backend show me all the logs and then emacs
> will search through them' then that would be required, but itʼs not,
> itʼs implemented as 'backend show me the logs which match STRING'

Again, it's about documentation and about commands doing things in a way 
that the user can anticipate.

>      Dmitry> E.g. whether "foo.txt" will only match literally, or whether "." can
>      Dmitry> be substituted by any character.
> 
> That will depend on the backend
> 
>      Dmitry> And if PATTERN is a regexp, what kind of regexp it's going to be
>      Dmitry> interepreted as: basic RE, extended RE, Emacs RE, or Perl RE (probably
>      Dmitry> not the last one anyway).
> 
> As will this
> 
>      Dmitry> I suppose we can choose one of these and say e.g. that pattern is
>      Dmitry> interpreted as an extended regular expression, except for some
>      Dmitry> backends that don't support that. I wonder how we're going to convey
>      Dmitry> the latter to the user.
> 
> Itʼs not a pattern. Itʼs a string that is passed as-is to the backend,
> which is free to interpret it as it wishes. From my viewpoint, we can
> just say
> 
> "Search for STRING, which is passed unsullied to the backend's log
> search command.  Consult the documentation for your backend to
> understand the matching method it uses to search for STRING."

IME this doesn't match the way we try to document commands in Emacs, but 
I wouldn't want to spend much time arguing about this.

Eli, could you weigh in in this discussion? Would you say Robert's 
proposal is acceptable?




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.