path: root/lockfile.c
diff options
authorMarcel M. Cary <>2009-02-18 03:00:43 (GMT)
committerJunio C Hamano <>2009-02-20 06:49:55 (GMT)
commit7d233dea5f4e299fdac8d6cfb610bcd4d60a82b7 (patch)
tree0db846c08686796a39fd9b10d321b30127ff60ee /lockfile.c
parent024aa7d8d5114f76e616a0ed8ddcf3b463ff2c14 (diff)
gitweb: Hyperlink multiple git hashes on the same commit message line
The current implementation only hyperlinks the first hash on a given line of the commit message. It seems sensible to highlight all of them if there are multiple, and it seems plausible that there would be multiple even with a tidy line length limit, because they can be abbreviated as short as 8 characters. Benchmark: I wanted to make sure that using the 'e' switch to the Perl regex wasn't going to kill performance, since this is called once per commit message line displayed. In all three A/B scenarios I tried, the A and B yielded the same results within 2%, where A is the version of code before this patch and B is the version after. 1: View a commit message containing the last 1000 commit hashes 2: View a commit message containing 1000 lines of 40 dots to avoid hyperlinking at the same message length 3: View a short merge commit message with a few lines of text and no hashes All were run in CGI mode on my sub-production hardware on a recent clone of git.git. Numbers are the average of 10 reqests per second with the first request discarded, since I expect this change to affect primarily CPU usage. Measured with ApacheBench. Note that the web page rendered was the same; while the new code supports multiple hashes per line, there was at most one per line. The primary purpose of scenarios 2 and 3 were to verify that the addition of 1000 commit messages had an impact on how much of the time was spent rendering commit messages. They were all within 2% of 0.80 requests per second (much faster). So I think the patch has no noticeable effect on performance. Signed-off-by: Marcel M. Cary <> Acked-by: Jakub Narebski <> Signed-off-by: Junio C Hamano <>
Diffstat (limited to 'lockfile.c')
0 files changed, 0 insertions, 0 deletions