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.
Cheers,
Daniel
Received on 2017-08-21 20:14:33 CEST