On Mon, Aug 21, 2017 at 8:14 PM, Daniel Shahaf <d...@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). -- Johan
