From: Jakub Narebski <jnareb@gmail.com>
To: "Marcel M. Cary" <marcel@oak.homeunix.org>
Cc: git@vger.kernel.org, fg@one2team.net, giuseppe.bilotta@gmail.com,
pasky@suse.cz
Subject: Re: [PATCH RFC 2/2] gitweb: Hyperlink multiple git hashes on the same commit message line
Date: Wed, 18 Feb 2009 22:55:11 +0100 [thread overview]
Message-ID: <200902182255.13983.jnareb@gmail.com> (raw)
In-Reply-To: <1234926043-7471-2-git-send-email-marcel@oak.homeunix.org>
On Wed, 18 Feb 2009, Marcel M. Cary wrote:
> 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.
That is a good catch. Code simply was not modified since we required
fill-length 40-characters SHA-1 id.
>
> 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
I don't think we should worry about that; after all esc_path and
unescape subroutines also use 'e' switch to Perl regexp.
So the benchmark is nice addition, but I don't think it is really
necessary, especially that the change results in shorter and easier
(I think) to maintain code.
[...]
> 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
Do I understand correctly that those patches are not related at all
semantically or textually, only in that you have them one after other
(and blob sha-1 in the index line reflects state after former), isn't
it?
>
>
> 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;
> +
Almost correct... but for this unnecessary 'return' statement.
Without it: ACK.
> return $line;
> }
>
> --
> 1.6.1
>
>
P.S. Why bare emails (without user names), e.g. "pasky@suse.cz"
and not "Petr Baudis <pasky@suse.cz>"? Just curious...
--
Jakub Narebski
Poland
next prev parent reply other threads:[~2009-02-18 21:57 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-08 19:07 [RFC] Configuring (future) committags support in gitweb Jakub Narebski
2008-11-08 20:02 ` Francis Galiegue
2008-11-08 22:35 ` Jakub Narebski
2008-11-08 23:27 ` Francis Galiegue
2008-11-09 0:25 ` Jakub Narebski
2009-02-17 15:32 ` [RFC] Configuring (future) committags support in gitweb, especially bug linking Marcel M. Cary
2009-02-18 3:00 ` [PATCH RFC 1/2] gitweb: Fix warnings with override permitted but no repo override Marcel M. Cary
2009-02-18 7:41 ` Giuseppe Bilotta
2009-02-18 8:40 ` Junio C Hamano
2009-02-18 13:09 ` Jakub Narebski
2009-02-18 19:02 ` Junio C Hamano
2009-02-18 3:00 ` [PATCH RFC 2/2] gitweb: Hyperlink multiple git hashes on the same commit message line Marcel M. Cary
2009-02-18 21:55 ` Jakub Narebski [this message]
2009-02-20 8:35 ` Junio C Hamano
2009-02-20 11:46 ` Jakub Narebski
2009-02-24 15:38 ` Addresses with full names in patch emails Marcel M. Cary
2009-02-24 15:58 ` Jakub Narebski
2009-02-24 16:33 ` [PATCH RFC 2/2] gitweb: Hyperlink multiple git hashes on the same commit message line Marcel M. Cary
2009-02-18 3:38 ` [RFC] Configuring (future) committags support in gitweb, especially bug linking Jakub Narebski
2009-02-19 17:08 ` Marcel M. Cary
2009-06-19 14:13 ` [RFC PATCH 1/2] gitweb: Hyperlink various committags in commit message with regex Marcel M. Cary
2009-06-22 11:18 ` Jakub Narebski
2009-11-18 6:22 ` [RFC PATCH 0/6] Second round of committag series Marcel M. Cary
2009-11-18 6:22 ` [RFC PATCH 1/6] gitweb: Hyperlink committags in a commit message by regex matching Marcel M. Cary
2009-11-18 6:22 ` [RFC PATCH 2/6] gitweb: Add second-stage matching of bug IDs in bugzilla committag Marcel M. Cary
2009-11-18 6:22 ` [RFC PATCH 3/6] gitweb: Allow finer-grained override controls for committags Marcel M. Cary
2009-11-18 6:22 ` [RFC PATCH 4/6] gitweb: Allow committag pattern matches to span multiple lines Marcel M. Cary
2009-11-18 6:22 ` [RFC PATCH 5/6] gitweb: Allow per-repository definition of new committags Marcel M. Cary
2009-11-18 6:22 ` [RFC PATCH 6/6] gitweb: Add _defaults_ keyword for feature lists in project config Marcel M. Cary
2009-11-18 8:20 ` [RFC PATCH 1/6] gitweb: Hyperlink committags in a commit message by regex matching Petr Baudis
2009-11-18 8:26 ` Petr Baudis
2009-11-20 23:24 ` [RFC PATCH 0/6] Second round of committag series Jakub Narebski
2009-06-19 14:13 ` [RFC PATCH 2/2] gitweb: Add second-stage matching of bug IDs in bugzilla committag Marcel M. Cary
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200902182255.13983.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=fg@one2team.net \
--cc=git@vger.kernel.org \
--cc=giuseppe.bilotta@gmail.com \
--cc=marcel@oak.homeunix.org \
--cc=pasky@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.