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.
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
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.
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.
-- Stefan^2.
Received on 2017-09-01 14:12:15 CEST