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

Re: [PATCHv2 0/8] gitweb: Faster and improved project search

From
Junio C Hamano <gitster@pobox.com>
Date
Feb 16, 2012, 20:40 UTC
Message-ID
<7vmx8iy0ix.fsf@alter.siamese.dyndns.org>
In-Reply-To
<1329338332-30358-1-git-send-email-jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
Show 18 quoted lines
> [Cc-ing Junio because of his involvement in discussion about first
>  patch in previous version of this series.]
>
> First three patches in this series are mainly about speeding up
> project search (and perhaps in the future also project pagination).
> Well, first one is unification, refactoring and future-proofing.
> The second and third patch could be squashed together; second adds
> @fill_only, but third actually uses it.
>
> Next set of patches is about highlighting matched part, making it
> easier to recognize why project was selected, what we were searching
> for (though better page title would also help second issue).
>
> Well, fourth patch (first in set mentioned above) is here for the
> commit message, otherwise it could have been squashed with next one.
>
> Last patch in this series is beginning of using esc_html_match_hl()
> for other searches in gitweb -- the easiest part.

Notice that you never said anything about what you wanted to achieve with this entire series? " -- the easiest part." does not mean anything. The easiest part of what?

Where in the series do the "faster" and "improved" come from? What do you exactly mean by "faster" and "improved"? In which commit would we find the answers to the questions like:

 - What operation was slow and how you tackled that slowness?
 - What are the benchmark results?

In general, "improve" is such a loaded word (after all, patches sent to the list are almost always meant to "improve" things) that it almost does not convey a single bit of information. Are you fixing bugs? Are you tidying up an unreadable piece of code? Are you fixing styles? Are you producing prettier output? Are you refactoring cut-and-pasted repetition into a common helper function? Are you adding a new feature?

Previous: Jakub NarebskiNext: Jakub Narebski
Message 13 of 16 in “[PATCHv2 0/8] gitweb: Faster and improved project search”
  1. Jakub NarebskiFeb 15, 2012
  2. 1/8 gitweb: Refactor checking if part of project info need fillingJakub Narebski, Feb 15, 2012
  3. 2/8 gitweb: Option for filling only specified info in fill_project_list_infoJakub Narebski, Feb 15, 2012
  4. Junio C HamanoFeb 20, 2012
  5. Jakub NarebskiFeb 22, 2012
  6. 3/8 gitweb: Faster project searchJakub Narebski, Feb 15, 2012
  7. Junio C HamanoFeb 20, 2012
  8. 4/8 gitweb: Introduce esc_html_hl_regionsJakub Narebski, Feb 15, 2012
  9. 5/8 gitweb: Highlight matched part of project name when searching projectsJakub Narebski, Feb 15, 2012
  10. 6/8 gitweb: Highlight matched part of project description when searching projectsJakub Narebski, Feb 15, 2012
  11. 7/8 gitweb: Highlight matched part of shortened project descriptionJakub Narebski, Feb 15, 2012
  12. 8/8 gitweb: Use esc_html_match_hl() in 'grep' searchJakub Narebski, Feb 15, 2012
  13. Junio C HamanoFeb 16, 2012
  14. Jakub NarebskiFeb 16, 2012
  15. Junio C HamanoFeb 20, 2012
  16. Jakub NarebskiFeb 22, 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.