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

Re: [PATCH] gitweb: Better chopping in commit search results

From
Jakub Narebski <jnareb@gmail.com>
Date
Feb 22, 2008, 17:49 UTC
Message-ID
<200802221849.44054.jnareb@gmail.com>
In-Reply-To
<7voda8ap6r.fsf@gitster.siamese.dyndns.org>
On Fri, 22 Feb 2008, Junio C Hamano wrote:
Show 19 quoted lines
> Jakub Narebski <jnareb@gmail.com> writes:
> 
>> From: Junio C Hamano <gitster@pobox.com>
>> Subject: [PATCH] gitweb: Better chopping in commit search results
>>
>> When searching commit messages (commit search), if matched string is
>> too long, the generated HTML was munged leading to an ill-formed XHTML
>> document.
>>
>> Now gitweb chop leading, trailing and matched parts, HTML escapes
>> those parts, then composes and marks up match info.  HTML output is
>> never chopped.  Limiting matched info to 80 columns (with slop) is now
>> done by dividing remaining characters after chopping match equally to
>> leading and trailing part, not by chopping composed and HTML marked
>> output.
> 
> Could somebody test this with very long search string, as that
> was how the issue initially came up, to see (1) if it really
> fixes the "mark-up chopped in the middle" issue, (2) [...]

The bug in question was cause by the chop _after_ doing HTML markup. Now gitweb chops, then HTML escapes, and chops no more. There is no way this bug can happen now.

BTW if commit messages follows "wrap at 76 column" convention it is not easy to test this condition... :-) 

But you are right that output should be improved...
Show 11 quoted lines
> For example, if you are looking for "very long ... and how"
> in the first paragraph of message (if it were all on a single
> line), wouldn't you want to see:
> 
>     ...st this with <<very long ... and how>> the actual out...
> 
> rather than:
> 
>     Could som... <<very long search stri...>> the actual out...
> 
> in the result?
...but I think it is better left for another patch.

P.S. When testing this commit I have noticed that currently, probably due to some misquoting, or interaction between escapemeta and quoting, searching for messages which contain "'" (apostrophe), e.g. "don't" currently doesn't work. Will investigate...

-- 
Jakub Narebski
Poland
Previous: Junio C HamanoNext: Jakub Narebski
Message 6 of 16 in “Do not chop HTML tags in commit search result”
  1. Do not chop HTML tags in commit search resultJean-Baptiste Quenot, Feb 13, 2008
  2. Jakub NarebskiFeb 13, 2008
  3. Junio C HamanoFeb 13, 2008
  4. gitweb: Better chopping in commit search resultsJakub Narebski, Feb 22, 2008
  5. Junio C HamanoFeb 22, 2008
  6. Jakub NarebskiFeb 22, 2008
  7. Jakub NarebskiFeb 22, 2008
  8. gitweb: Option to chop at beginning and in the middle in chop_strJakub Narebski, Feb 23, 2008
  9. Junio C HamanoFeb 23, 2008
  10. Jakub NarebskiFeb 23, 2008
  11. gitweb: Option to chop at beginning and in the middle in chop_strJakub Narebski, Feb 24, 2008
  12. Junio C HamanoFeb 25, 2008
  13. gitweb: Better cutting matched string and its contextJakub Narebski, Feb 25, 2008
  14. Junio C HamanoFeb 25, 2008
  15. Karl HasselströmFeb 23, 2008
  16. Jakub NarebskiFeb 23, 2008

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.