git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH (BUGFIX)] gitweb: Fix fixed string (non-regexp) project search

From
Jakub Narebski <jnareb@gmail.com>
Date
Mar 4, 2012, 18:00 UTC
Message-ID
<201203041900.32114.jnareb@gmail.com>
In-Reply-To
<201203031156.00948.jnareb@gmail.com>
Jakub Narebski wrote:
Show 45 quoted lines
> On Sat, 3 Mar 2012, Junio C Hamano wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>> 
>>> Use $search_regexp, where regex metacharacters are quoted, for
>>> searching projects list, rather than $searchtext, which contains
>>> original search term.
>>>
>>> Reported-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
>>> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
>>> ---
>>> I think this bug was here from the very beginning of adding project
>>> search, i.e. from  v1.6.0.2-446-g0d1d154 (gitweb: Support for simple
>>> project search form, 2008-10-03)  which was present since 1.6.1
>>>
>>> On Fri, 2 Mar 2012, Ramsay Jones wrote:
>>> 
>>>> This patch solves the problem for me when using a regex search
>>>> (re checkbox checked), but *not* for a non-regex search.
>>>> 
>> 
>> This patch depends on the more recent changes than the regexp fix, no?  I
>> was hoping that we could merge the earlier fix for the regexp case to
>> older maintenance tracks later, but if we were going to do so, we would
>> want to do the same for a fix for fixed-string case.
> 
> The regexp and non-regexp bugs and fixes are different.
> 
> The regexp "bug" was just us forgetting that regexp is provided by user
> input, and should be validated.  The bug as reported by Ramsay was here
> from the very beginning, i.e. commit 0e55991 (gitweb: Clearly distinguish
> regexp / exact match searches, 2008-02-26), which was present in v1.5.1
> if I have checked correctly.  The fix is about adding new code and should
> apply cleanly to 'maint' and even to older versions; the only trouble
> with older version might be whitespace issue related to refactoring
> code into subroutines.
> 
> The non-regexp project search bug was using $searchtext instead of
> $search_regexp as search regexp in gitweb.  The bug was present from
> the very addition of project search, namely commit 0d1d154 (gitweb:
> Support for simple project search form, 2008-10-03), which was present
> in v1.5.1 if I have checked correctly.  Unfortunately the fix affects
> code that was changed recently in a1e1b2d (gitweb: improve usability
> of projects search form, 2012-01-31); I'll try to come up with equivalent
> patch to 'maint' soon (if the current one does not apply, and I guess it
> doesn't).

In other words: while "*foo" is invalid regular expression, it is perfectly valid fixed string search term (which translates to "\*foo" regexp).

-- 
Jakub Narebski
Poland
Previous: Jakub NarebskiNext: Junio C Hamano
Message 9 of 18 in “gitweb: Handle invalid regexp in regexp search”
  1. gitweb: Handle invalid regexp in regexp searchJakub Narebski, Feb 28, 2012
  2. Junio C HamanoFeb 28, 2012
  3. Jakub NarebskiFeb 29, 2012
  4. Ramsay JonesMar 2, 2012
  5. gitweb: Fix fixed string (non-regexp) project searchJakub Narebski, Mar 2, 2012
  6. Junio C HamanoMar 3, 2012
  7. Jakub NarebskiMar 3, 2012
  8. gitweb: Fix fixed string (non-regexp) project searchJakub Narebski, Mar 4, 2012
  9. Jakub NarebskiMar 4, 2012
  10. Junio C HamanoMar 4, 2012
  11. Junio C HamanoMar 5, 2012
  12. Jakub NarebskiMar 5, 2012
  13. Jakub NarebskiMar 5, 2012
  14. Junio C HamanoMar 5, 2012
  15. Ramsay JonesMar 5, 2012
  16. Junio C HamanoMar 5, 2012
  17. Jakub NarebskiMar 6, 2012
  18. Jakub NarebskiMar 6, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.