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
