Jakub Narebski <jnareb@xxxxxxxxx> writes: > [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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html