webgit highlightes mem adresses as git versions

webgit highlightes mem adresses as git versions

[Toralf Förster]

As seen here 
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.27.y.git;a=commit;h=8ca2918f99b5861359de1805f27b08023c82abd2 
the strings [<c043d0f3>] and firends shouldn't be recognized as git hashes, 
isn't it ?

-- 
MfG/Sincerely

Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

Re: webgit highlightes mem adresses as git versions

[Jakub Narebski]

Toralf Förster <toralf.foerster@gmx.de> writes:

> As seen here 
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.27.y.git;a=commit;h=8ca2918f99b5861359de1805f27b08023c82abd2 
> the strings [<c043d0f3>] and firends shouldn't be recognized as git hashes, 
> isn't it ?

Gitweb, not webgit.  And gitweb considers ([0-9a-fA-F]{8,40}) i.e.
from 8 to 40 hexadecimal characters to be (shortened) SHA-1.  It
simply cannot afford checking if such object exists when displaying
commit message (for example in 'log' view).

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: webgit highlightes mem adresses as git versions

[Toralf Förster]

At Monday 02 February 2009 23:54:20 Jakub Narebski wrote :
> Toralf Förster <toralf.foerster@gmx.de> writes:
> > As seen here
> > http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.27.y.git;a=com
> >mit;h=8ca2918f99b5861359de1805f27b08023c82abd2 the strings [<c043d0f3>]
> > and firends shouldn't be recognized as git hashes, isn't it ?
>
> Gitweb, not webgit.  And gitweb considers ([0-9a-fA-F]{8,40}) i.e.
> from 8 to 40 hexadecimal characters to be (shortened) SHA-1.  It
> simply cannot afford checking if such object exists when displaying
> commit message (for example in 'log' view).

Ah - ok, what's about expecting spaces around such SHA-1 keys ?

-- 
MfG/Sincerely

Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

Re: webgit highlightes mem adresses as git versions

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1177 bytes --]

Hi,

On Tue, 3 Feb 2009, Toralf Förster wrote:

> At Monday 02 February 2009 23:54:20 Jakub Narebski wrote :
> > Toralf Förster <toralf.foerster@gmx.de> writes:
> > > As seen here
> > > http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.27.y.git;a=com
> > >mit;h=8ca2918f99b5861359de1805f27b08023c82abd2 the strings [<c043d0f3>]
> > > and firends shouldn't be recognized as git hashes, isn't it ?
> >
> > Gitweb, not webgit.  And gitweb considers ([0-9a-fA-F]{8,40}) i.e.
> > from 8 to 40 hexadecimal characters to be (shortened) SHA-1.  It
> > simply cannot afford checking if such object exists when displaying
> > commit message (for example in 'log' view).
> 
> Ah - ok, what's about expecting spaces around such SHA-1 keys ?

Won't fly: there was a recommendation at some point that you should refer 
to commits in such a form:

	2819075(Merge branch 'maint-1.6.0' into maint)

However, gitweb being written in Perl, I think a lookbehind like (?<!0x), 
i.e. that a 0x in front of the hexadecimal characters means it is no 
SHA-1.

Even better would be using word boundaries, I guess, but all that fails 
when you have a hexdump in the commit message.

Ciao,
Dscho

[PATCH] gitweb: Better regexp for SHA-1 committag match

[Jakub Narebski]

On Tue, 3 Feb 2009, Johannes Schindelin wrote:
> On Tue, 3 Feb 2009, Toralf Förster wrote:
>> At Monday 02 February 2009 23:54:20 Jakub Narebski wrote :
>>> Toralf Förster <toralf.foerster@gmx.de> writes:

>>>> As seen here
>>>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.27.y.git;a=commit;h=8ca2918f99b5861359de1805f27b08023c82abd2 the strings [<c043d0f3>]
>>>> and firends shouldn't be recognized as git hashes, isn't it ?
>>>
>>> Gitweb, not webgit.  And gitweb considers ([0-9a-fA-F]{8,40}) i.e.
>>> from 8 to 40 hexadecimal characters to be (shortened) SHA-1.  It
>>> simply cannot afford checking if such object exists when displaying
>>> commit message (for example in 'log' view).
>> 
>> Ah - ok, what's about expecting spaces around such SHA-1 keys ?
> 
> Won't fly: there was a recommendation at some point that you should refer 
> to commits in such a form:
> 
> 	2819075(Merge branch 'maint-1.6.0' into maint)
> 
> However, gitweb being written in Perl, I think a lookbehind like (?<!0x), 
> i.e. that a 0x in front of the hexadecimal characters means it is no 
> SHA-1.
> 
> Even better would be using word boundaries, I guess, but all that fails 
> when you have a hexdump in the commit message.

Here you have it: anchoring SHA-1 regexp to word boundary. It would
help eliminate _some_ of false matches.

-- >8 --
Subject: [PATCH] gitweb: Better regexp for SHA-1 committag match

Make SHA-1 regexp to be turned into hyperlink (the SHA-1 committag)
to match word boundary at the beginning and the end.  This way we
reduce number of false matches, for example we now don't match
0x74a5cd01 which is hex decimal (for example memory address),
but is not SHA-1.

Suggested-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
 gitweb/gitweb.perl |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index f27dbb6..bec1af6 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1364,7 +1364,7 @@ sub format_log_line_html {
 	my $line = shift;
 
 	$line = esc_html($line, -nbsp=>1);
-	if ($line =~ m/([0-9a-fA-F]{8,40})/) {
+	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),
-- 
1.6.1

Re: [PATCH] gitweb: Better regexp for SHA-1 committag match

[Rafael Garcia-Suarez]

2009/2/6 Jakub Narebski <jnareb@gmail.com>:
> Make SHA-1 regexp to be turned into hyperlink (the SHA-1 committag)
> to match word boundary at the beginning and the end.  This way we
> reduce number of false matches, for example we now don't match
> 0x74a5cd01 which is hex decimal (for example memory address),
> but is not SHA-1.

Further suggestion: you could also turn the final \b into (\b|\@), so
it skips stuff that might look like a message-id.
Here's an example :
http://perl5.git.perl.org/perl.git/commit/f57255841c18e91c7a719a2400645e39398f3947
(We get loads of this in the Perl repository)

> Suggested-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
>  gitweb/gitweb.perl |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index f27dbb6..bec1af6 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1364,7 +1364,7 @@ sub format_log_line_html {
>        my $line = shift;
>
>        $line = esc_html($line, -nbsp=>1);
> -       if ($line =~ m/([0-9a-fA-F]{8,40})/) {
> +       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),
> --
> 1.6.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
"You don't mean odds and ends, you mean des curieux et des bouts",
corrected the manager.
-- Terry Pratchett, Hogfather

Re: [PATCH] gitweb: Better regexp for SHA-1 committag match

[Jakub Narebski]

Dnia piątek 6. lutego 2009 10:49, Rafael Garcia-Suarez napisał:
> 2009/2/6 Jakub Narebski <jnareb@gmail.com>:

> > Make SHA-1 regexp to be turned into hyperlink (the SHA-1 committag)
> > to match word boundary at the beginning and the end.  This way we
> > reduce number of false matches, for example we now don't match
> > 0x74a5cd01 which is hex decimal (for example memory address),
> > but is not SHA-1.
> 
> Further suggestion: you could also turn the final \b into (\b|\@),

You meant \b -> \b(?!\@), didn't you?  Word boundary _not_ followed
by '@', and not word boundary _OR_ '@' as you wrote...

> so it skips stuff that might look like a message-id.
> Here's an example :
> http://perl5.git.perl.org/perl.git/commit/f57255841c18e91c7a719a2400645e39398f3947

For those who do not want to open browser, it is:

Message-ID: <46A0F33545E63740BC7563DE59CA9C6D0939A0@exchsvr2.npl.ad.local>

> (We get loads of this in the Perl repository)

> > -       if ($line =~ m/([0-9a-fA-F]{8,40})/) {
> > +       if ($line =~ m/\b([0-9a-fA-F]{8,40})\b/) {

-- 
Jakub Narebski
Poland

Re: [PATCH] gitweb: Better regexp for SHA-1 committag match

[Rafael Garcia-Suarez]

2009/2/6 Jakub Narebski <jnareb@gmail.com>:
> Dnia piątek 6. lutego 2009 10:49, Rafael Garcia-Suarez napisał:
>> 2009/2/6 Jakub Narebski <jnareb@gmail.com>:
>
>> > Make SHA-1 regexp to be turned into hyperlink (the SHA-1 committag)
>> > to match word boundary at the beginning and the end.  This way we
>> > reduce number of false matches, for example we now don't match
>> > 0x74a5cd01 which is hex decimal (for example memory address),
>> > but is not SHA-1.
>>
>> Further suggestion: you could also turn the final \b into (\b|\@),
>
> You meant \b -> \b(?!\@), didn't you?  Word boundary _not_ followed
> by '@', and not word boundary _OR_ '@' as you wrote...

Ah right, shame on me.

[PATCHv2] gitweb: Better regexp for SHA-1 committag match

[Jakub Narebski]

Make SHA-1 regexp to be turned into hyperlink (SHA-1 committag)
to match word boundary at beginning and end.  This way we limit
false matches, for example 0x74a5cd01 which is hex decimal (for
example memory address) but not SHA-1.

Also make sure that it is not Message-ID, which fragment just
looks like SHA-1 (e.g. "Message-ID: <46A0F335@example.com>"),
by using zero-width negative look-ahead assertion to _not_
match '@' after.

Suggested-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Suggested-by: Rafael Garcia-Suarez <rgarciasuarez@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
v2: Added protection against matching Message-IDs fragments.

 gitweb/gitweb.perl |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index f27dbb6..5dcc108 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1364,7 +1364,7 @@ sub format_log_line_html {
 	my $line = shift;
 
 	$line = esc_html($line, -nbsp=>1);
-	if ($line =~ m/([0-9a-fA-F]{8,40})/) {
+	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),
-- 
1.6.1

Re: [PATCHv2] gitweb: Better regexp for SHA-1 committag match

[Johannes Schindelin]

Hi,

On Fri, 6 Feb 2009, Jakub Narebski wrote:

> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index f27dbb6..5dcc108 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1364,7 +1364,7 @@ sub format_log_line_html {
>  	my $line = shift;
>  
>  	$line = esc_html($line, -nbsp=>1);
> -	if ($line =~ m/([0-9a-fA-F]{8,40})/) {
> +	if ($line =~ m/\b([0-9a-fA-F]{8,40})\b(!?\@)/) {

Looks good to me!

Thanks,
Dscho

Re: [PATCHv2] gitweb: Better regexp for SHA-1 committag match

[Jay Soffian]

On Fri, Feb 6, 2009 at 8:03 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 6 Feb 2009, Jakub Narebski wrote:
>
>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>> index f27dbb6..5dcc108 100755
>> --- a/gitweb/gitweb.perl
>> +++ b/gitweb/gitweb.perl
>> @@ -1364,7 +1364,7 @@ sub format_log_line_html {
>>       my $line = shift;
>>
>>       $line = esc_html($line, -nbsp=>1);
>> -     if ($line =~ m/([0-9a-fA-F]{8,40})/) {
>> +     if ($line =~ m/\b([0-9a-fA-F]{8,40})\b(!?\@)/) {
>
> Looks good to me!

I wonder if just matching lower-case a-f would be sufficient as well?

j.

Re: [PATCHv2] gitweb: Better regexp for SHA-1 committag match

[Jakub Narebski]

Jay Soffian wrote:
> On Fri, Feb 6, 2009 at 8:03 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>> On Fri, 6 Feb 2009, Jakub Narebski wrote:
>>
>>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>>> index f27dbb6..5dcc108 100755
>>> --- a/gitweb/gitweb.perl
>>> +++ b/gitweb/gitweb.perl
>>> @@ -1364,7 +1364,7 @@ sub format_log_line_html {
>>>       my $line = shift;
>>>
>>>       $line = esc_html($line, -nbsp=>1);
>>> -     if ($line =~ m/([0-9a-fA-F]{8,40})/) {
>>> +     if ($line =~ m/\b([0-9a-fA-F]{8,40})\b(!?\@)/) {
>>
>> Looks good to me!
> 
> I wonder if just matching lower-case a-f would be sufficient as well?

Well... 

On one hand side git generates always lower-case a-f for SHA-1.
On the other hand git _accepts_ upper-case A-F for SHA-1 of object.

-- 
Jakub Narebski
Poland

Re: [PATCHv2] gitweb: Better regexp for SHA-1 committag match

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Make SHA-1 regexp to be turned into hyperlink (SHA-1 committag)
> to match word boundary at beginning and end.  This way we limit
> false matches, for example 0x74a5cd01 which is hex decimal (for
> example memory address) but not SHA-1.
>
> Also make sure that it is not Message-ID, which fragment just
> looks like SHA-1 (e.g. "Message-ID: <46A0F335@example.com>"),
> by using zero-width negative look-ahead assertion to _not_
> match '@' after.

Your message I am responding to is:

    Message-ID: <200902061149.16210.jnareb@gmail.com>

Does your description mean that "200902061149" would match, because the
LAA will say "Ah, dot is not an at-sign"?

Re: [PATCHv2] gitweb: Better regexp for SHA-1 committag match

[Jakub Narebski]

Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > Make SHA-1 regexp to be turned into hyperlink (SHA-1 committag)
> > to match word boundary at beginning and end.  This way we limit
> > false matches, for example 0x74a5cd01 which is hex decimal (for
> > example memory address) but not SHA-1.
> >
> > Also make sure that it is not Message-ID, which fragment just
> > looks like SHA-1 (e.g. "Message-ID: <46A0F335@example.com>"),
> > by using zero-width negative look-ahead assertion to _not_
> > match '@' after.
> 
> Your message I am responding to is:
> 
>     Message-ID: <200902061149.16210.jnareb@gmail.com>
> 
> Does your description mean that "200902061149" would match, because the
> LAA will say "Ah, dot is not an at-sign"?

It would unfortunately falsely match... but we cannot eliminate this
case (well, at least not checking if hexnumber is followed by dot),
because of totally legitimate

   ... at commit 8457bb9e.

So even with that we would have still false matches...
-- 
Jakub Narebski
Poland

Re: [PATCHv2] gitweb: Better regexp for SHA-1 committag match

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> It would unfortunately falsely match... but we cannot eliminate this
> case (well, at least not checking if hexnumber is followed by dot),
> because of totally legitimate
>
>    ... at commit 8457bb9e.
>
> So even with that we would have still false matches...

Yeah, so what's the value in v2 over v1?  It is still wrong but it is less
wrong than it used to be?  I think the word-boundary one made a good
sense.  I do not see the @lookahead adding much value at all.

Re: [PATCHv2] gitweb: Better regexp for SHA-1 committag match

[Jakub Narebski]

Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > It would unfortunately falsely match... but we cannot eliminate this
> > case (well, at least not checking if hexnumber is followed by dot),
> > because of totally legitimate
> >
> >    ... at commit 8457bb9e.
> >
> > So even with that we would have still false matches...
> 
> Yeah, so what's the value in v2 over v1?  It is still wrong but it is less
> wrong than it used to be?  I think the word-boundary one made a good
> sense.  I do not see the @lookahead adding much value at all.

Right. So v2 is less useful that I thought it to be; and adding further
"exceptions" doesn't seem like a good idea.  The 'msgid' committag
when/if it gets implemented would help there...

So please take v1, as it is sane improvement and generic enough.
-- 
Jakub Narebski
Poland

Re: [PATCHv2] gitweb: Better regexp for SHA-1 committag match

[demerphq]

2009/2/7 Jakub Narebski <jnareb@gmail.com>:
> Junio C Hamano wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>> > It would unfortunately falsely match... but we cannot eliminate this
>> > case (well, at least not checking if hexnumber is followed by dot),
>> > because of totally legitimate
>> >
>> >    ... at commit 8457bb9e.
>> >
>> > So even with that we would have still false matches...
>>
>> Yeah, so what's the value in v2 over v1?  It is still wrong but it is less
>> wrong than it used to be?  I think the word-boundary one made a good
>> sense.  I do not see the @lookahead adding much value at all.
>
> Right. So v2 is less useful that I thought it to be; and adding further
> "exceptions" doesn't seem like a good idea.  The 'msgid' committag
> when/if it gets implemented would help there...
>
> So please take v1, as it is sane improvement and generic enough.

If you make it configurable then everybody can be happy right?

Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: [PATCHv2] gitweb: Better regexp for SHA-1 committag match

[Jakub Narebski]

On Sat, 7 Feb 2009, demerphq wrote:
> 2009/2/7 Jakub Narebski <jnareb@gmail.com>:
>> Junio C Hamano wrote:
>>> Jakub Narebski <jnareb@gmail.com> writes:
>>>
>>>> It would unfortunately falsely match... but we cannot eliminate this
>>>> case (well, at least not checking if hexnumber is followed by dot),
>>>> because of totally legitimate
>>>>
>>>>    ... at commit 8457bb9e.
>>>>
>>>> So even with that we would have still false matches...
>>>
>>> Yeah, so what's the value in v2 over v1?  It is still wrong but it is less
>>> wrong than it used to be?  I think the word-boundary one made a good
>>> sense.  I do not see the @lookahead adding much value at all.
>>
>> Right. So v2 is less useful that I thought it to be; and adding further
>> "exceptions" doesn't seem like a good idea.  The 'msgid' committag
>> when/if it gets implemented would help there...
>>
>> So please take v1, as it is sane improvement and generic enough.
> 
> If you make it configurable then everybody can be happy right?

That are the long term plans, to implement generic 'committags' support
(which would include current SHA-1 and signoff committags).

BTW. it is the 'configurable' part that makes it difficult... ;-)
-- 
Jakub Narebski
Poland

Re: [PATCHv2] gitweb: Better regexp for SHA-1 committag match

[Jakub Narebski]

Dnia piątek 6. lutego 2009 11:49, Jakub Narebski napisał:

> +	if ($line =~ m/\b([0-9a-fA-F]{8,40})\b(!?\@)/) {

+	if ($line =~ m/\b([0-9a-fA-F]{8,40})\b(?!\@)/) {

Not that it matters, because adding such single-case exceptions
is not a good idea, so it is v1 which would be (I hope) in git.

-- 
Jakub Narebski
Poland

Re: [PATCH] gitweb: Better regexp for SHA-1 committag match

[demerphq]

2009/2/6 Jakub Narebski <jnareb@gmail.com>:
> Dnia piątek 6. lutego 2009 10:49, Rafael Garcia-Suarez napisał:
>> 2009/2/6 Jakub Narebski <jnareb@gmail.com>:
>
>> > Make SHA-1 regexp to be turned into hyperlink (the SHA-1 committag)
>> > to match word boundary at the beginning and the end.  This way we
>> > reduce number of false matches, for example we now don't match
>> > 0x74a5cd01 which is hex decimal (for example memory address),
>> > but is not SHA-1.
>>
>> Further suggestion: you could also turn the final \b into (\b|\@),
>
> You meant \b -> \b(?!\@), didn't you?  Word boundary _not_ followed
> by '@', and not word boundary _OR_ '@' as you wrote...

Since \b(?!\@) is effectively two zero width negative assertions in a
row you could simplify by saying:

  (?![^\w\@])

and that way you can easily add the '.' case as well.

Yves










-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: [PATCH] gitweb: Better regexp for SHA-1 committag match

[Jakub Narebski]

On Sat, 7 Feb 2009, demerphq wrote:
> 2009/2/6 Jakub Narebski <jnareb@gmail.com>:
>> Dnia piątek 6. lutego 2009 10:49, Rafael Garcia-Suarez napisał:
>>> 2009/2/6 Jakub Narebski <jnareb@gmail.com>:

>>>> Make SHA-1 regexp to be turned into hyperlink (the SHA-1 committag)
>>>> to match word boundary at the beginning and the end.  This way we
>>>> reduce number of false matches, for example we now don't match
>>>> 0x74a5cd01 which is hex decimal (for example memory address),
>>>> but is not SHA-1.
>>>
>>> Further suggestion: you could also turn the final \b into (\b|\@),
>>
>> You meant \b -> \b(?!\@), didn't you?  Word boundary _not_ followed
>> by '@', and not word boundary _OR_ '@' as you wrote...
> 
> Since \b(?!\@) is effectively two zero width negative assertions in a
> row you could simplify by saying:
> 
>   (?![^\w\@])

I don't know if "sth\b" is effectively "sth(!?[^\w])"... perhaps it is.

> 
> and that way you can easily add the '.' case as well.

We cannot add '.' case, because it there can be legitimate SHA-1 match
ending sentence, e.g.

     ... at commit 8457bb9e.

-- 
Jakub Narebski
Poland

Re: [PATCH] gitweb: Better regexp for SHA-1 committag match

[demerphq]

2009/2/7 Jakub Narebski <jnareb@gmail.com>:
> On Sat, 7 Feb 2009, demerphq wrote:
>> 2009/2/6 Jakub Narebski <jnareb@gmail.com>:
>>> Dnia piątek 6. lutego 2009 10:49, Rafael Garcia-Suarez napisał:
>>>> 2009/2/6 Jakub Narebski <jnareb@gmail.com>:
>
>>>>> Make SHA-1 regexp to be turned into hyperlink (the SHA-1 committag)
>>>>> to match word boundary at the beginning and the end.  This way we
>>>>> reduce number of false matches, for example we now don't match
>>>>> 0x74a5cd01 which is hex decimal (for example memory address),
>>>>> but is not SHA-1.
>>>>
>>>> Further suggestion: you could also turn the final \b into (\b|\@),
>>>
>>> You meant \b -> \b(?!\@), didn't you?  Word boundary _not_ followed
>>> by '@', and not word boundary _OR_ '@' as you wrote...
>>
>> Since \b(?!\@) is effectively two zero width negative assertions in a
>> row you could simplify by saying:
>>
>>   (?![^\w\@])
>
> I don't know if "sth\b" is effectively "sth(!?[^\w])"... perhaps it is.

Sorry, my bad, that is double negation, I meant (?![\w\@])

On of the ways you can express \b is as:
(?:(?<=\w)(?!\w)|(?<=\W)(?!\W)|\A)

But the point here is you are looking for the end of a hex sequence,
so you can just use the "end of string" bit of the alternation which
is: (?!\w).

>>
>> and that way you can easily add the '.' case as well.
>
> We cannot add '.' case, because it there can be legitimate SHA-1 match
> ending sentence, e.g.
>
>     ... at commit 8457bb9e.

/(?<!\w)([a-fA-F0-9]+)(?!(?:\.\w|[\w@]))/

:-)

Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"