Johan Corveleyn wrote:
> On Mon, Aug 21, 2017 at 8:14 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
>> Julian Foad wrote on Mon, 21 Aug 2017 14:09 +0100:
>>> Also the search term seems to be required to match the entire path, so I
>>> need to write "co*" rather than just "co" to match "configure.ac". That
>>> is inconsistent with "svn log --search" which looks for the pattern as a
>>> substring even when matching paths. I think differences such as this are
>>> bad.
>>
>> From the peanut gallery, I'm not sure about this. When one greps log
>> messages, I think it is far more common to search for a _substring_ of
>> the log message than to ask for all revisions whose log messages are
>> strcmp()-equal to a particular string.
>>
>> On the other hand, with paths, it's plausible that one would know the
>> exact basename being sought, and wouldn't be interested in filenames
>> that contain that basename as a substring.
>>
>> Further, with glob patterns, if the CLI implements exact matching, users
>> can achieve either exact matching (default) or substring matching (by
>> adding * before and after the pattern), whereas if the client implemented
>> substring matching, there would be no way for users to request exact
>> matching: fnmatch() doesn't have an equivalent of regexes' ^ and $
>> anchors.
>>
>> But I haven't thought much about this. There may well be logic to the
>> current behaviour that I'm overlooking.
>
> FWIW, I agree with Daniel's argumentation here about doing exact
> matching with --list (and requiring *'s for substring matching).
So do I.
I also think, for consistency and for the reasons above, we should
change 'svn log --search' so that when searching in the changed paths it
works this way too. Then 'foo' and '*foo*' would have different meanings
when searching in the changed paths. When searching in fields such as
the log message, it would keep the existing behaviour whereby both of
those search terms would mean a substring search.
That would be a backwards-incompatible change, but to a non-prominent
and undocumented detail of the UI, and for good reasons. Does that make
sense?
- Julian
Received on 2017-08-25 13:51:59 CEST