Stefan Fuhrmann wrote:
> On 01.09.2017 13:30, Stefan Sperling wrote:
>> On Fri, Sep 01, 2017 at 06:36:46AM +0200, Stefan Fuhrmann wrote:
>>> Because I think that strict glob-like patterns need to be supported
>>> as well, I suggest to have two options:
>>>
>>> --search does a fuzzy search just like we use it in other commands.
>>> We implicitly add leading an trailing '*'.
>>>
>>> --search-glob performs a fully case- and accent-sensitive glob
>>> matching.
>>>
>>> As with '--search' alone, the user is free to specify any number
>>> and combination of the above but without the support of '--search-and' -
>>> at least for now.
>>>
>>> Thoughts? Better names for '--search-glob'?
>>
>> I don't see a need to invent a new option name.
>>
>> I would say it's OK to have --search options with slightly different
>> semantics for different subcommands. Their semantics just shouldn't
>> be entirely different. If one matches case-sensitively and the other
>> does not, I would say that's too different. But I don't think we
>> need to be consistent about implicit *-globbing rules.
>>
>> So having 'svn list --search' do what you describe above as
>> 'svn list --search-glob' would be entirely acceptable to me.
(I'm unsure exactly what you meant there, stsp -- that seems to
contradict the previous paragraph, if 'svn log --search remains
case-insensitive.)
Mainly I think about the issue this way: What is the benefit to the user
if path matching in "svn list --search" works differently from path
matching in "svn log --search"? I see no benefit and some harms if it
works differently.
Altogether it feels like we are getting close to letting ourselves
produce something confusing just because we are thinking about what's
useful for one particular use case at a time, and/or because the
implementation happens to be already structured in such a way, and I
think we should step back a bit. How would we want to explain the search
option to the users?
> Yeah, my impression is that most people don't see a need
> for an exact matching option. And given that the "fuzzy"
> matching will rarely produce false negatives, users could
> easily post-filter the results if they want to remove
> false positives.
>
> That would leave us with 'svn ls --search' working almost
> exactly like 'svn list --search', except that we must not
(I assume you meant "exactly like 'svn log --search'".)
> add implicit '*' globs on both sides of the pattern. If
> we did that "*.c" would match "hallo.cpp", and that would
> be confusing to most users.
Another aspect that I'm not sure about is how they match a whole path:
"svn log --search" seems to match the pattern against the whole path,
not treating slashes specially: pattern "trunk*.c" would match path
"/subversion/trunk/subversion/svn/svn.c"). On the other hand, "svn list
--search" seems to match the pattern against just one path component at
a time -- possibly just the last component? I haven't tested it enough
to know, nor seen it documented.
If that behaviour is completely different between "log" and "list"...
that's another source of confusion that I think we should address one
way or another.
> So, if there are no strong opinions against it, I will undo
> the "--pattern" option commit and change the matching code
> to case- and accent-insensitive.
That part sounds good to me.
- Julian
Received on 2017-09-01 16:01:38 CEST