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

[PATCH RFC 2/2] gitweb: Hyperlink multiple git hashes on the same commit message line

From
Marcel M. Cary <marcel@oak.homeunix.org>
Date
Feb 18, 2009, 03:00 UTC
Message-ID
<1234926043-7471-2-git-send-email-marcel@oak.homeunix.org>
In-Reply-To
<1234926043-7471-1-git-send-email-marcel@oak.homeunix.org>

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 <marcel@oak.homeunix.org>
---
And here's another.
Marcel
 gitweb/gitweb.perl |   12 +++++-------
 1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 653f0be..51b7f56 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1384,13 +1384,11 @@ sub format_log_line_html {
 	my $line = shift;
 
 	$line = esc_html($line, -nbsp=>1);
-	if ($line =~ m/\b([0-9a-fA-F]{8,40})\b/) {
-		my $hash_text = $1;
-		my $link =
-			$cgi->a({-href => href(action=>"object", hash=>$hash_text),
-			        -class => "text"}, $hash_text);
-		$line =~ s/$hash_text/$link/;
-	}
+	$line =~ s{\b([0-9a-fA-F]{8,40})\b}{
+		return $cgi->a({-href => href(action=>"object", hash=>$1),
+					   -class => "text"}, $1);
+	}eg;
+
 	return $line;
 }
 
-- 
1.6.1
Previous: Marcel M. CaryNext: Jakub Narebski
Message 8 of 20 in “[RFC] Configuring (future) committags support in gitweb”
  1. Jakub NarebskiNov 8, 2008
  2. Francis GaliegueNov 8, 2008
  3. Jakub NarebskiNov 8, 2008
  4. Francis GaliegueNov 8, 2008
  5. Jakub NarebskiNov 9, 2008
  6. Marcel M. CaryFeb 17, 2009
  7. 1/2 gitweb: Fix warnings with override permitted but no repo overrideMarcel M. Cary, Feb 18, 2009
  8. 2/2 gitweb: Hyperlink multiple git hashes on the same commit message lineMarcel M. Cary, Feb 18, 2009
  9. Jakub NarebskiFeb 18, 2009
  10. Junio C HamanoFeb 20, 2009
  11. Jakub NarebskiFeb 20, 2009
  12. Addresses with full names in patch emailsMarcel M. Cary, Feb 24, 2009
  13. Jakub NarebskiFeb 24, 2009
  14. Marcel M. CaryFeb 24, 2009
  15. Giuseppe BilottaFeb 18, 2009
  16. Junio C HamanoFeb 18, 2009
  17. Jakub NarebskiFeb 18, 2009
  18. Junio C HamanoFeb 18, 2009
  19. Jakub NarebskiFeb 18, 2009
  20. Marcel M. CaryFeb 19, 2009

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.